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EXECUTIVE  SUMMARY 


The  evaluation  of  the  Blueline  phase  of  the  Farmington  Demonstration  Project 
was  conducted  by  two  separate  groups.  The  Users  Team  evaluated  whether  the 
Blueline  met  user  requirements  as  determined  by  the  Farmington  Resource  Area 
staff.  This  team  was  led  by  John  Singlaub,  Grand  Junction  Resource  Area 
Manager.  The  team's  results  were  presented  in  a separate  document  and  are 
reprinted  as  Appendix  A.  The  Technical  Team  evaluated  the  technical  issues  of 
the  development  process  as  well  as  management  concerns  and  issues.  This  team 
was  led  by  Greg  Graff,  ALMRS-GIS  Project  Support  Staff  Chief.  The  evaluation 
report  synthesizes  the  findings  of  both  groups. 

The  purpose  of  this  evaluation  was  to  document  lessons  learned  from  the  effort. 
This  report  describes  the  tasks  in  the  development  process,  identifies  problem 
areas  and  issues,  and  explores  the  potential  application  of  a similar  type 
system  to  the  Bureau. 

Goals  and  objectives,  therefore,  were  to  examine  the  tasks,  validate  whether 
user  requirements  were  met,  and  report  the  findings  to  Bureau  management. 

Major  findings  were  as  follows: 

° The  system  is  easy-to-use  and  effectively  performs  the  Application  for 
Permit  to  Drill  (APD)  process  as  identified  by  the  Farmington  Resource 
Area . 

° The  importance  of  data  management  was  again  shown  to  be  a major 

issue.  The  UNIX  software  made  the  conversion  of  the  data  easier,  and 
the  ORACLE  relational  data  base  management  system  gave  the  capability 
to  easily  manipulate  and  manage  the  data.  Consistency  in  automated 
data,  standardized  entry  format,  along  with  quality  assurance  controls 
must  be  of  primary  importance  to  the  Bureau. 

° Ad  hoc  query  capability  is  a necessity  for  providing  information  to 
assist  in  decisionmaking,  allowing  data  searches  for  special  projects 
and  allowing  for  better  versatility  and  use  of  the  system. 

° The  modular  concepts  provide  for  ease  of  maintenance  and  eliminate  the 
need  to  write  similar  types  of  modules  for  each  case  type,  thus 
requiring  only  the  addition  of  case-specific  modules. 

° The  Blueline,  as  developed  thus  far  and  envisioned  for  operation, 
demonstrated  how  users  require  spatial  graphics  as  an  essential/ 
critical  tool  for  land  management  activities  and  decisionmaking. 

° Although  commercial  off-the-shelf  software  will  save  substantial 

development  time,  it  does  not  completely  eliminate  the  need  for  custom 
code.  Some  custom  code  will  still  be  needed  to  tailor  system 
applications  to  functional  requirements. 

An  automated  Land  Information  System  is  a valid  and  valuable  tool  for  the 
Bureau  to  perform  its  land  managing  activities.  Further  automation  can 
provide  the  needed  capabilities  more  effectively  than  current  manual  systems 
or  procedures. 
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CHAPTER  I 


INTRODUCTION 


A.  PURPOSE 

The  Farmington  Demonstration  Project  was  originally  chartered  on  March  7, 
1986  to  prototype  automation  efforts  being  planned  by  the  Bureau  of  Land 
Management  (BLM).  The  project  was  divided  into  two  prototype  phases, 
Redline  and  Blueline,  to  meet  the  following  overall  objectives: 

° Define  the  strategy  for  the  organization  of  unintegrated  existing 
manual  and  automated  coordinate,  record,  and  resource  data  into  a 
format  for  automation; 

° Demonstrate,  in  a field  office  environment,  the  integration  of 
coordinates,  records,  and  resources  using  existing  data  bases, 
hardware,  and  software; 

° Demonstrate  the  integration  of  coordinates,  records,  and  resources 
using  developmental  software  and  new  hardware; 

° Define  functional  and  system  requirements  for  an  interim  Land 
Information  System  (LIS); 

° Further  clarify  functional  and  system  requirements  for  a future  LIS 
system  and  produce  a written  summary  of  results  to  integrate  into  the 
Bureau's  Modernization  Request  for  Proposal  (RFP). 

The  purpose  of  the  first  phase  of  the  project  (Redline)  was  to  demonstrate, 
in  a field  setting,  the  potential  to  integrate  coordinate,  record,  and 
resource  data  into  an  integrated  single  data  base  (the  type  needed  for  an 
LIS),  using  existing  hardware  and  software.  This  phase  was  completed  on 
February  6,  1987,  and  an  evaluation  report  was  issued  on  April  24,  1987. 

The  Blueline  phase,  which  is  the  focus  of  this  report,  determined  the 
amount  of  increased  capability  that  could  be  obtained  through  the  use  of 
new  commercial  off-the-shelf  (COTS)  software  and  a new  generation  of 
hardware.  The  Blueline  further  demonstrated  how  a user-defined  technology 
would  fit  the  needs  of  the  field. 

As  with  the  Redline,  the  Blueline  used  the  Application  for  Permit  to  Drill 
(APD)  as  the  vehicle  to  demonstrate  these  capabilities  because  it 
represents  a significant  part  of  the  Bureau's  workload  and  because  the 
requirements  for  processing  data  for  an  APD  are  similar  to  many  other  case 
processing  functions  in  the  Bureau.  APDs  were  divided  into  three 
categories — Adjudication,  Drilling  and  Production,  and  Fluid  Surface 
Management — to  accommodate  the  three  different  groups  of  people  who  work 
on  APDs.  The  case  itself  is  divided  into  three  steps,  legal  determination, 
conflict  determination,  and  mitigation,  which  lend  themselves  to  almost 
any  case  the  Bureau  works  on  in  the  field  as  long  as  the  appropriate  data 
is  included  in  the  data  base.  The  majority  of  the  functional  requirements 
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identified  by  the  users  were  included  in  the  Blueline  process.  Those 
functions  not  included,  such  as  split  screens,  were  omitted  because  of 
time  constraints  or  because  additional  software  packages  would  have  had  to 
be  purchased.  Purchasing  additional  software  was  not  feasible  because 
many  of  the  functions  had  been  performed  during  the  Redline  phase,  and  the 
project  was  intended  as  a demonstration  only,  not  a production  system. 

The  purpose  of  this  evaluation  is  to  document  what  BLM  learned  from  the 
Blueline  prototype  effort.  This  report  describes  tasks,  identifies 
problem  areas  and  issues,  and  explores  the  potential  application  of  a 
system  like  the  Blueline  within  the  Bureau.  As  with  the  Redline, 
information  from  this  evaluation  will  be  presented  to  the  Field  Committee 
and  Bureau  Management  Team  for  review  and  discussion  of  the  Demonstration 
Project's  overall  objectives. 

B.  GOALS  AND  OBJECTIVES  OF  THE  BLUELINE  EVALUATION 

The  primary  goal  of  the  Blueline  prototype  was  to  demonstrate,  in  a field 
setting,  the  effectiveness  of  using  developmental  software  as  well  as  a 
new  generation  of  hardware  to  automate  an  integrated  data  base  to  include 
coordinate,  record,  and  resource  data.  Its  focus  was  to  demonstrate  a 
user-driven  system  that  met  the  needs  of  the  field. 

To  meet  this  goal,  the  evaluation  team  objective  was  to  examine  the 
following  steps  taken  in  developing  the  Blueline  demonstration: 

° Analysis  of  the  current  manual  APD  process,  as  Farmington  accomplishes 
this  task; 

° Procedures  for  developing  and  writing  specifications; 

° Computer  coding  and  recording; 

° Testing; 

° Evaluation  of  the  Blueline  demonstration; 

° Examination  of  the  effectiveness  of  new  capabilities  in  meeting  user 
needs  and  supporting  an  LIS  in  the  Bureau; 

° Report  of  the  findings  for  evaluation  and  consideration  by  the  Field 
Committee  and  Bureau  Management  Team. 

C.  SCOPE  AND  METHODOLOGY  OF  THE  BLUELINE  EVALUATION 

The  Blueline  evaluation  is  essentially  two  evaluations,  user  and  technical 
(Figure  1).  The  user  portion  concentrates  on  the  Blueline's  capability  to 
meet  user  requirements.  The  technical  portion  concentrates  on  the 
technical  issues  involving  Blueline  development.  While  this  report 
focuses  on  these  two  issues,  management  concerns  and  recommendations  are 
also  addressed. 
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FARMINGTON  BLUELINE  DEMONSTRATION  EVALUATION 

THE  USER  GROUP  IS  EVALUATING  THE  DEMONSTRATION  SYSTEM  AGAINST  THE  USER  REQUIREMENTS 
THE  TECHNICAL  GROUP  IS  EVALUATING  THE  SYSTEM  SPECIFICATIONS  AND  DESIGN  BOTH 
EVALUATIONS  ARE  NEEDED  PRIOR  TO  MAKING  THE  SYSTEM  OPERATIONAL  AND  COMPLETING  THE 
RFP  SPECIFICATIONS  FOR  THE  TARGET  LI.S. 


-4- 


The  evaluation  team  divided  into  two  groups  to  concentrate  fully  on  the 
individual  issues.  While  each  group  tried  to  focus  on  only  its  part  of 
the  evaluation,  as  with  any  team  effort,  the  findings  often  overlapped. 

The  groups  worked  independently  with  only  the  team  leaders  coordinating 
the  evaluation.  Interestingly,  for  overlapping  areas,  the  findings  of  one 
team  supported  those  of  the  other. 

D.  MAJOR  FINDINGS  OF  THE  BLUELINE  EVALUATION 

Major  findings  of  the  Users  portion  of  the  evaluation  fall  under  the 
following  three  topics — feasibility,  system,  and  user  requirements.  Some 
of  the  specific  findings  are  as  follows: 

° Methods  by  which  the  same  task  is  accomplished  by  the  various  offices 
are  not  entirely  consistent. 

° The  system  as  a whole  is  easy-to-use  and  effectively  performs  the  APD 
process . 

° The  Blueline,  as  developed  so  far  and  envisioned  for  operation,  demon- 
strated how  users  require  spatial  graphics  as  an  essential  tool  for 
this  and  most  other  Bureau  activities. 

° The  Blueline  graphics  provided  a rapid  and  comprehensive  means  of 
identifying  conflicts  and  deficiencies,  while  tying  data  to  actual 
points  on  the  earth.  They  also  clarified  needs  for  mitigation  and 
approval  by  showing  problem  areas. 

° Data  was  integrated  and  the  system  gave  easy  access  to  record, 
resource,  and  coordinate  data. 

° Ad  hoc  query  capability  is  a necessity  for  providing  information  to 

assist  in  decisionmaking,  allowing  data  searches  for  special  projects, 
and  offering  both  versatility  and  use  of  the  system. 

° Additional  data  fields,  edit  capability,  and  enhancements  were 
identified . 

Major  findings  of  the  technical  portion  of  the  evaluation  fall  under  the 
following  four  topics — functionality,  development,  data,  and  management. 
Some  of  these  findings  are  as  follows: 

° The  modular  concept  eliminates  the  need  to  write  similar  types  of 
modules  for  all  case  types  and  requires  only  those  modules  that  are 
case-specific.  This  concept  also  lends  itself  to  easy  maintenance. 

° While  a detailed  evaluation  of  ADP  support  needs  was  not  conducted, 
both  users  and  managers  believe  these  needs  must  be  assessed  for  all 
levels  of  the  Bureau  (e.g.,  system  administrators,  programmers,  etc.). 
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Data  quality  improved  with  the  Blueline,  primarily  due  to  the 
following: 

Match/ Merge  Software  - Increased  data  quality  and  eliminated  the 
need  to  reformat  because  it  reformatted  legal  land  description 
as  it  converted  three  types  of  data  into  one  data  set. 

However,  it  did  not  convert  action  codes. 

ORACLE  - Helped  alleviate  the  data  structure  problems  that  occurred 
with  the  Redline  and  gave  users  the  capability  to  manipulate 
the  data  easily  and  fast. 

Parcel  Generator  Software  - Assisted  in  quality  control  of 

duplicate  data  sets  and  errors  as  it  graphically  displayed 
alphanumeric  legal  land  descriptions.  However,  data  struc- 
tures, consistency,  and  quality  are  still  problems.  The 
Bureau  will  need  to  emphasize  data  collection,  consistency, 
and  standardization  (especially  resource  data) — to  ensure 
quality  products  and  a high  level  of  confidence  in  computer 
technology.  Additional  analysis,  testing,  implementation,  and 
maintenance  plans  for  a broad  range  of  data  issues  are 
warranted . 

Technical  personnel — data,  programming,  and  systems — along  with  field 
specialists  should  be  an  integral  part  of  the  specification  writing 
team  to  ensure  a quality  document  that  will  be  easily  understood  by 
the  programming  staff. 

Future  efforts  should  ensure  continuity  in  the  analysis  and 
development  of  an  automated  system — one  analysis  method  should  be 
carried  forward,  and  one  accountable  manager  should  begin  and  end  the 
process.  Technical  and  functional  experts  must  work  as  a team  in 
every  aspect  of  building  a new  system.  When  this  type  of  team  was  in 
place,  the  analysis  and  development  moved  much  faster,  the  goals 
stayed  within  established  timeframes,  and  a quality  product  was 
generated . 

The  developmental  software  and  hardware  were  good  programming  tools, 
giving  the  programmers  the  utilities  and  flexibility  needed  to  meet 
user  requirements  for  the  Blueline.  This  flexibility  meets  a large 
portion  of  the  Bureau's  functional  requirements  for  the  Target  System. 

COTS  software  packages  meet  the  basic  functional  requirements  and  save 
developmental  time.  Of  the  necessary  custom  code,  most  was  required 
for  specific  user  interfaces.  The  amount  of  custom  code  needed  will 
be  proportionate  to  specific  needs;  custom  code  can  be  limited  by 
building  good  generic  screens  to  accommodate  a multitude  of  case  types. 

The  method  used  to  define  user  requirements  and  then  translate  them  in 
system  specifications  did  not  give  systems  designers/programmers 
adequate  information  to  develop  the  Blueline. 

User  specifications  must  concentrate  on  what  the  system  should  do 
rather  than  on  how  it  should  be  programmed. 
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The  Bureau  procurement  system  needs  to  be  streamlined  to  ensure  timely 
delivery  of  hardware  and  software.  The  Farmington  Project  was 
adversely  affected  by  the  required  number  of  reviews  and  approvals. 
Because  of  the  procurement  process,  at  least  ^40,000  was  lost;  the 
schedule  slipped;  and  we  were  required  to  fund  again  in  the  next 
fiscal  year. 

The  Bureau  needs  to  continue  to  analyze  and  dissect  ongoing  activities 
before  proceeding  with  a Target  System.  Spinoffs  from  the  demonstra- 
tion are  showing  that  the  character  of  the  Bureau's  business  is 
beginning  to  change.  Many  office  roles  and  functions  will  need  to  be 
redefined  before  the  benefits  of  a Target  System  can  be  maximized. 


-7- 


CHAPTER  II 


USERS  GROUP  EVALUATION  REPORT 

A.  PURPOSE  OF  THE  USERS  EVALUATION 

This  portion  of  the  report  documents  the  user  findings  and  concerns 
associated  with  the  Blueline  phase  of  the  Farmington  Demonstration 
Project.  The  thrust  of  this  part  of  the  evaluation  was  to  determine  how 
well  user  requirements  were  met  and  whether  the  identified  user 
requirements  have  Bureau  application. 

Specifically,  the  Users  Group  looked  at  the  following  areas: 

1.  Capability  of  the  system  to  perform  APD  processing  functions  as 
identified  by  Farmington  resource  specialists; 

2.  Capability  of  the  system  to  perform  APD  processing  functions  in  other 
Bureau  offices,  given  typical  procedural  differences; 

3.  Benefits  or  problems  associated  with  using  the  demonstration  system; 

4.  Recommendations  for  improving  the  system  to  make  it  operational; 

5.  User  considerations  for  designing  future  systems. 

B.  SCOPE  OF  THE  USERS  EVALUATION 

The  scope  of  the  users'  evaluation  encompassed  examination  and  analyses  of 
the  following: 

1.  The  effectiveness  of  the  system  to  perfom  the  APD  process  from 
receipt  to  approval; 

2.  The  potential  of  using  this  type  of  system  for  other  Bureau  processes; 
and 

3.  Ease  of  use. 

The  team  looked  closely  at  the  two  completed  modules — the  Adjudication 
Module  and  the  Drilling  and  Production  Module — and  examined  the  system 
specifications  of  the  remaining  modules  to  get  a feel  for  the  anticipated 
total  system.  (Other  APD  capabilities  had  been  demonstrated  during  the 
Redline  phase  and  were,  therefore,  not  repeated  for  the  Blueline  phase.) 
The  team  believed  that  sufficient  work  had  been  completed  on  the  Blueline 
package  to  assess  the  process  used  to  develop  the  APD  processing  system. 

C.  METHODOLOGY  OF  THE  USERS  EVALUATION 
1 . Evaluation  Team 

A small  evaluation  team  was  selected  to  represent  a good  cross-section 
of  the  resource  specialists  involved  in  the  APD  process,  as  well  as  a 
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geographic  mix  to  gather  different  perspectives  from  different  offices 
The  following  individuals  were  included  on  the  team: 

John  Singlaub  (Team  Leader),  Area  Manager,  Grand  Junction 
Resource  Area,  Colorado. 

Jamie  Connell,  Petroleum  Engineer,  Miles  City  District  Office, 
Montana. 

Clare  Miller,  Environmental  Scientist,  Great  Divide  Resource  Area, 
Rawl ins , Wyoming . 

Jim  Salas,  Geologist,  Roswell  District  Office,  New  Mexico. 

Linda  Slone,  Land  Law  Examiner,  Platte  River  Resource  Area, 

Casper,  Wyoming. 


2.  Approach 

The  team  members  met  in  Denver  and  were  briefed  on  the  background, 
purpose,  and  objectives  of  the  Farmington  Demonstration  Project  and 
the  Blueline  phase.  Greg  Graff,  John  Foster,  Sam  Montgomery,  and  Jeff 
Nighbert  brought  the  team  up  to  date  on  the  project  and  the  process 
used  to  arrive  at  the  demonstration  system.  Judy  Bright  gave  the  team 
a detailed  demonstration  of  the  completed  modules. 

The  team  members  then  had  the  opportunity  to  operate  the  system 
themselves  to  simulate  actual  case  use.  This  hands-on  opportunity  to 
use  the  system  served  as  a typical  (though  brief)  production  test  for 
the  APD  modules.  This  would  normally  be  a first  step  in  getting  a 
production  system  operational  for  field  use.  In  the  course  of  the 
test,  several  idiosyncracies  and  "bugs"  appeared  (as  would  normally  be 
expected),  which  discouraged  some  of  the  team  members. 

The  team  then  reviewed  the  system  specifications  for  all  modules  and 
discussed  them  with  New  Mexico  and  Service  Center  personnel  for 
clarification.  The  team  also  consulted  their  professional  counterpart 
elsewhere  in  the  Bureau  for  procedural  differences. 

The  team  documented  the  benefits  and  problems  of  the  system  as  they 
perceived  them  and  proposed  recommendations  for  changes  or  improve- 
ments. (The  complete  Users  Group  Evaluation  Report  is  included  as 
Appendix  A;  the  major  points  of  the  evaluation  follow.) 

D.  USERS  EVALUATION 

1 . Feasibility 


This  portion  of  the  evaluation  addresses  the  applicability  of  this 
type  of  system  to  an  LIS  for  the  Bureau.  The  team  felt  that  this  is 
exactly  the  kind  of  development  effort  on  which  the  Service  Center 
should  be  focusing  its  time.  The  technology  is  today's  technology, 
and  the  systems  are  available  (or  will  be  soon)  in  each  Bureau  office. 
Benefits  to  the  field  in  implementing  Bureau  programs  is  most  evident 
in  this  kind  of  application. 

Finding  1.  One  problem  observed  by  the  team  dealt  with  the  apparent  incon 
sistency  in  the  way  the  same  task  is  carried  out  by  different  offices 
within  the  Bureau.  Applicable  handbooks  and  manuals  outline  the 
general  requirements,  but  individual  offices  accomplish  the  mission  by 
different  methods.  Minor  differences  occur  such  as  varying  checklists 


-9- 


and  data  entry  forms.  Major  differences  are  encountered  when  reviewing 
the  distribution  of  responsibilities  among  different  types  of 
specialists  involved  in  a common  process. 

Recommendation.  These  discrepancies  between  offices  will  become  signifi- 
cant as  automated  systems  are  developed.  To  meet  the  demands  of  auto- 
mation, the  Bureau  has  two  basic  options.  To  gain  acceptability  in 
the  field,  each  automated  process  should  include  built-in  flexibility 
to  account  for  differences  among  offices.  Or,  the  Bureau  may  want  to 
take  the  opportunity  to  build  in  consistency  and  standardize  processes 
where  clear  advanatages  to  the  program  or  agency  would  accrue.  This 
would  require  BLM  managers  to  apply  the  same  logic  required  to  develop 
computer  programs  as  they  would  to  develop  their  resource  programs. 


Finding  2.  As  we  automate  processes  in  the  BLM,  we  are  discovering  flaws 
in  the  way  we  are  currently  doing  business.  These  problems  include 
such  things  as  performing  duplicate  work,  maintaining  multiple  records 
or  files,  creating  bottlenecks  in  work  flow,  etc. 

Recommendation.  Detailed  evaluations  of  job  functions  are  required  in 

order  to  automate  work  steps.  As  these  evaluations  uncover  inefficient 
or  inappropriate  work  flows  or  processes,  we  should  give  serious  con- 
sideration to  changing  the  way  we  do  business.  Analysis  and  possible 
restructuring  of  individual  jobs  or  work  processes  would  be  beneficial 
to  the  agency  as  a whole. 

2.  System 

This  discussion  includes  observations  on  the  overall  system  as 
completed  for  the  Blueline — the  Adjudicative  and  Drilling  and 
Production  modules,  and  the  system  design  as  anticipated  for  the 
remaining  modules.  The  system  as  defined  or  envisioned  effectively 
performs  the  APD  process  from  adjudication  for  conflict  analysis/ 
resolution  through  consolidation  and  approval. 

The  process  for  evaluating  an  APD  will  be  greatly  affected.  Once  the 
data  is  initially  entered  into  the  system,  the  paper  mill  process  will 
be  virtually  eliminated.  Checklists  and  confirmation  sheets  will  be 
automated  along  with  plats  and  pertinent  maps.  Information  shared 
will  increase  since  work  from  some  modules  is  transparently  transferred 
into  other  modules.  Some  paper  'work'  copies  of  information  may  be 
generated  in  the  process  for  various  reasons,  but  these  copies  may  not 
necessarily  become  part  of  the  official  file.  Invisible  access  to 
other  software  (PC  or  mini)  will  further  streamline  and  enhance  the 
overall  process.  If  properly  developed,  the  status  of  each  APD  or 
work  accomplished  in  the  process  may  be  easily  displayed  and  reviewed 
by  managers  or  others. 

Consolidation  of  data  themes  into  an  LIS  is  necessary  to  derive  maximum 
benefit  from  individual  systems.  The  system  provides  for  user  effec- 
tiveness by  making  access  to  the  various  data  sources  virtually 
invisible.  Efficiency  in  the  processing  of  individual  APDs  should  be 
improved  through  the  elimination  of  much  of  the  paper  shuffling  associ- 
ated with  manual  operations.  The  capability  of  comparing  operator- 
submitted  data  with  the  Bureau's  data  bases  is  another  advantage  of 
automation. 
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General  Observations.  The  Blueline  APD  system  is  capable  of  accessing 
different  record  and  coordinate  data  and  spatial  resource  data  bases 
with  little  effort  on  the  part  of  the  user.  This  invisible 
programming  significantly  improves  the  accessibility  and  useability  of 
the  system  for  even  the  casual  user.  To  perform  these  tasks  without 
the  relational  data  base  management  system  and  the  menu-based  macro 
programming  could  be  extremely  difficult,  time-consuming,  and  too 
technically  demanding  for  the  average  user. 

Technological  advances  exhibited  by  the  Blueline  were  invisible  to  the 
user  group,  but  we  felt  they  were  a principal  benefit  of  the  Blueline 
APD  system. 

Finding  1.  One  of  our  concerns  was  the  uncertainty  about  what  hardcopy 
files  had  been  replaced  by  the  automated  system. 

Recommendation.  In  any  situation  where  a manual  process  is  replaced  by  an 
automated  process,  significant  thought  must  be  given  to  the  automated 
products  and  which  hardcopy  files  they  will  replace. 


Finding  2.  Information  on  the  system  as  a whole  is  easy  to  enter  and 
follow.  The  menus  and  help  screens  provide  a user-friendly 
environment . 

Recommendation.  Interactive  help  screens  and  messages  should  be  further 
developed  to  aid  novice  and  part-time  users.  Replace  'X'  responses  with 
•Y'  or  'N'. 


Finding  3.  The  use  of  graphics  greatly  benefits  all  spatial  evaluations. 
Graphic  presentations  provide  a more  effective  means  of  accomplishing 
the  goals  of  the  APD  process  while  allowing  the  approving  official  to 
easily  verify  the  professional  findings.  Routine  drafting  requirements 
will  also  be  met. 

Recommendation.  The  use  of  graphics  should  be  applied  to  data  input 

forms.  Simple  use  of  color  and  lines  or  boxes  enhancing  areas  of  the 
input  forms  will  provide  for  a more  user-friendly  environment  and 
simplify  data  input  and  extraction.  Better  cursor  control  through  the 
use  of  a mouse  or  the  arrow  keys  is  a must. 

Graphic  queries  should  be  further  developed.  Through  the  use  of 
crosshairs  or  a cursor,  attributes  for  anything  displayed  on  the 
screen  could  be  pinpointed. 


Finding  4.  The  interactive  nature  of  the  APD  system  permits  each  of  the 
participants  in  the  APD  approval  process  to  access  current,  updated 
data  and  approvals  as  they  occur  and  reduces  the  overall  paper  flow  in 
the  field  offices  considerably. 

One  of  the  primary  benefits  of  the  demonstration  system  is  that  it  pro- 
vided a rapid  and  comprehensive  means  of  identifying  APD  conflicts  and 
deficiencies  as  well  as  mitigation  and  approval  formats.  If  implement- 
ed, this  system  would  save  significant  time  in  completing  APD  reviews. 


Recommendation.  Transparent  exits  from  the  system  to  allow  the  use  and 

access  of  other  APD  resources  not  part  of  the  LIS  (PC  software,  ad  hoc 
queries,  MOSS)  must  be  provided. 

To  maximize  the  benefits  of  the  system,  the  capability  to  perform  ad 
hoc  queries  is  a necessity.  The  sheer  volume  of  information  available 
and  the  countless  ways  in  which  the  information  can  be  used  negates 
the  option  of  using  only  preprogrammed  reports.  Ad  hoc  reports  could 
be  used  to  provide  information  to  assist  management  in  decisionmaking; 
allow  data  searches  for  special  projects;  and,  in  general,  allow  the 
Bureau  better  versatility  and  use  of  the  system. 


Finding  5.  The  demonstration  neglected  the  inherent  need  to  process  an 
APD-related  Right-of-Way  (ROW).  In  some  offices,  processing  an 
APD-related  ROW  is  the  rule  and  not  the  exception.  Bureau  policy 
emphasizes  simultaneous  approval  of  the  APD  and  associated  ROW  (see 
WO  IM  No.  87-349). 

Recommendation.  Although  the  Fluids  Surface  Management  Module  (screens 
2 and  3)  can  be  used  to  identify  existing  and  needed  ROWs,  we 
recommend  that  an  ROW  adjudicative  screen  be  developed  and  added  to 
this  system.  By  developing  a screen  for  ROW  actions,  the 
demonstration  system  will  be  enhanced  and  will  provide  more  credibility 
to  this  automated  ADP  process. 

3.  Modules 

The  basic  concept  of  the  modules  is  excellent.  However,  due  to 
typical  procedural  differences  from  one  office  to  another,  several 
additional  needs  were  identified. 

The  modules  are  menu-driven  with  built-in  help  screens  that  make  the 
system  user-friendly.  A novice  with  the  aid  of  a simple,  documented 
users  manual  can  operate  the  system  easily.  The  automatic  transfer  of 
common  data  from  screen-to— screen  and  module-to— module  is  very  good. 

The  use  of  the  graphics  display  screen  will  minimize  the  time  required 
to  research  hardcopy  records  and  eliminate  the  manual  updating  of 
records  and  maps. 

General  Observations.  The  automation  of  the  adjudicative  function  and 

subsequent  linkage  of  Case  Recordation,  coordinate  data,  and  the  Master 
Name  File  improves  the  efficiency  of  the  adjudicative  process.  The 
program  eliminates  the  need  to  exit  one  system  and  enter  another  to 
retrieve  data,  resulting  in  substantial  time  savings. 

The  capability  to  display  spatial  data  graphically  eliminates  the 
necessity  to  maintain  oil  and  gas  field  maps  along  with  the  associated 
spacing  orders.  Master  Title  Plats,  etc. 

The  Drilling  and  Production  Module  provides  numerous  benefits  for  a 
technical  review  of  an  APD.  The  system  transmits  information  developed 
by  an  adjudicator  and  a geologist  to  the  engineer.  This  saves  time 
and  paper,  and  prevents  a duplication  of  work.  The  automated  8-point 
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Checklist  provides  a means  of  tracking  the  engineering  review  and 
generates  a 7-day  letter.  This  module  has  automated  the  geologist's 
report  and  easily  ports  the  information  to  the  engineer  for  the 
generation  of  the  wellbore  diagram. 

The  wellbore  graphics  portion  of  the  module  is  an  excellent  tool.  The 
program  allows  an  engineer  to  enter  pertinent  technical  information 
from  which  the  computer  retrieves  libraried  data  from  numerous  sources, 
calculates  cement  volumes,  and  generates  a wellbore  diagram.  This 
minimizes  the  time  an  engineer  spends  looking  up  values  in  cementing 
tables,  performing  tedious  volumetric  calculations,  and  drafting 
wellbore  diagrams. 

An  additional  observation  was  the  potential  advantage  of  linking  the 
APD  system  to  the  automated  systems.  We  assumed  that  these  modules 
would  not  be  a "closed"  system,  i.e.,  that  opportunities  would  be 
provided  for  users  to  exit  the  system  and  work  on  other  data  or 
analytical  systems,  or  to  export  data  to  other  systems  as  needed. 

These  modules  are  only  a part  of  the  overall  LIS  being  developed  by 
the  Bureau,  and  they  need  to  be  linked  via  the  data  base  management 
system  to  other  related  systems.  An  example  associated  with  APD 
processing  is  to  link  to  the  PC-based  Automated  Inspection  Record 
System  (AIRS),  and  to  transfer  data  automatically  to  that  system. 

Links  to  other  existing  systems  should  also  be  explored,  emphasizing 
links  to  both  alphanumeric  and  spatial  data.  Both  are  needed  to 
ensure  the  success  of  an  integrated  LIS. 

Finding  1.  The  programming  for  the  Fluid  Surface  Management,  Mitigation, 
and  Consolidation  modules  was  not  completed  or  was  unavailable  for  a 
"hands-on"  demonstration. 

Recommendation . Further  review  of  a demonstration  model  may  be  necessary 
for  a more  objective  and  complete  evaluation  if  this  was  not  settled 
during  the  Redline  phase. 


Finding  2.  Overall,  the  modules  ran  smoothly  and  appear  to  have  success- 
fully met  the  user  needs  identified  by  Farmington  personnel. 

Specific  needs  are  identified  in  Appendix  A,  but  generally  they  are  as 
follows : 

° Bond  and  Surety  interface  for  bonding  validation; 

° expanded  wellbore  diagram  capabilities  to  include  such  things 
as  wellbore  deviation  and  patented  mineral  conflicts; 

° legends  defining  shading,  angles,  and  color  hues; 

° menus  for  retrieval  of  map  themes; 

° provision  for  master  file  security  to  control  modification  by 
only  those  personnel  who  are  authorized; 

° provision  for  processing  APD-related  rights-of-way. 
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Recommendations . 


Recommendations  made  are  screen-specific.  They  can  be 
found  in  Appendix  A,  but  basically  are  within  the  purview  of  the 
following  areas: 

Add  data  fields  for  informations  such  as... 

• bottom  hole  location; 

• comments; 

• designation  of  operator; 

• spacing  unit  size; 

• multi-grade  casing. 

Add  edit  capability  for... 

• duplicate  entries; 

• well  location  within  lease,  unit,  and/or  Communitization 

Agreement  boundary . 

Enhance  developed  modules  to  include... 

• spacing  requirements; 

• interfaces  with  Bond  and  Surety  system; 

• spatial  representation  of  H2S  and  high  pressure  zones. 

Ensure  security  of  data  files  so  that  only  authorized  personnel 

may  change,  add,  or  delete. 

4.  User  Requirements 

We  are  impressed  by  the  significant  strides  made  by  the  Bureau  toward 
automation.  The  development  of  macros  and  the  use  of  data  base 
management  systems  to  access  different  data  bases  make  for  a friendly 
user  environment  to  process  a complex  action.  Benefits  to  the  field 
in  implementing  Bureau  programs  are  most  evident  in  this  kind  of 
application  plus,  by  introducing  Bureau  employees  to  an  automated 
process  with  clear  benefits  to  them,  we  have  gained  the  early  support 
of  users  for  future  implementation  of  a Target  System. 

The  Blueline  system  demonstrated  the  need  for  spatial  graphics  as  a 
critical  tool  for  this  and  most  other  Bureau  land  management 
activities.  As  future  systems  are  developed,  access  to  spatial 
graphics  data  bases  and  systems  and  analytical  methods  must  be 
included.  Further,  access  to  related  alphanumeric  data  bases, 
including  records  and  resource  data,  must  be  easily  accessible  to 
specialists  for  multiple  applications.  The  "invisibility"  to  the  user 
of  accessing  these  other  data  bases  in  the  demonstration  was  a 
significant  breakthrough  for  the  Blueline  effort. 

The  team  sees  the  potential  for  systems  such  as  these  to  provide  the 
opportunity  for  professionals  to  spend  more  time  doing  the  work  they 
were  hired  to  do  and  less  time  on  paper  chases.  While  we  were  unable 
to  quantify  the  potential  time  savings,  changes  in  work  flow  and 
skills  from  automation  could  bring  significant  benefits  to  the  agency. 

Finding  1.  The  issue  of  the  availability  of  technical  support  is  a 

question  that  needs  to  be  looked  at,  for  the  long  term,  by  the  Bureau 
as  a whole. 
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Recommendation.  Programmers  should  be  part  of  the  entire  automation 

process  to  help  users  and  to  resolve  problems.  Specifically,  the  need 
as  well  as  the  duties  of  a Systems  Administrator  need  to  be  explored. 


F inding  2 . For  the  Target  System  to  benefit  the  Resources  and  Mineral 

programs  as  well  as  other  programs,  professionals  need  to  shift  their 
emphasis  to  developing  and  maintaining  the  required  digital  data 
bases.  Professionals  will  need  to  control  and  influence  data  to 
instill  confidence  in  the  system  and  acceptance  of  the  results. 

Recommendation.  Serious  consideration  must  be  given  to  how  and  when  to 

compile  these  data  bases.  Since  this  type  of  work  requires  major  time 
commitments,  planning  and  development  of  these  data  bases  should  begin 
well  before  the  target  date.  Data  bases  need  to  be  developed  and 
maintainance  routines  established  so  the  Target  System  will  have 
reliable  data. 

Alternatively,  initial  data  collection  and  digitizing  could  be 
contracted  with  the  data  later  maintained  by  the  Bureau  staffs. 
Traditional  flows  of  information  may  have  to  be  changed  to  provide 
staff  members  with  the  data  required  for  this  maintenance. 
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CHAPTER  III 


TECHNICAL  GROUP  EVALUATION  REPORT 


A.  PURPOSE  OF  THE  TECHNICAL  EVALUATION 

This  part  of  the  report  documents  the  findings  and  issues  associated  with 
the  Blueline  development.  The  thrust  of  this  portion  of  the  evaluation 
was  to  determine  what  went  right  or  wrong  during  the  Blueline  development 
and  to  transfer  the  information  to  the  teams  working  on  the  Bureau's 
Modernization  RFP. 

Specifically,  the  Technical  Evaluation  Team  interviewed  the  people  who, 
through  their  involvement,  could  respond  to  the  following  areas  of  the 
Blueline : 

1.  Development  of  specifications  and  how  well  they  reflected  user 
requirements ; 

2.  Ease/difficulty  of  designing  and  developing  a system,  using  the  newest 
ADP  technologies,  to  meet  user  requirements; 

3.  Type  of  user  support  required  to  run  the  system  in  a field  setting; 

4.  Data  problems,  documented  in  the  Redline  Evaluation,  still  occurring 
with  Blueline  technology; 

5.  Functions,  other  than  those  demonstrated  by  the  Redline,  that  could  be 
performed  with  the  Blueline. 

B.  SCOPE  OF  THE  TECHNICAL  EVALUATION 

The  scope  of  the  technical  evaluation  encompassed  analyses  of  the 
following : 

1.  Methodologies  used  to  develop  system  specifications,  systems  design, 
data  base  construction,  and  user  interfaces; 

2.  The  effectiveness  of  new  hardware  and  software  in  meeting  processing 
requirements  for  an  APD;  and 

3.  Management  issues  surrounding  potential  use  of  this  technology 
throughout  the  Bureau. 

Some  of  the  issues  identified  by  managers  were  outside  the  specific  scope 
of  the  Blueline  evaluation.  These  issues  are  mentioned  in  this  report  but 
not  analyzed.  We  recommend  that  another  evaluation  team  be  assigned  the 
responsibility  of  analyzing  these  issues  and  report  its  findings  to  the 
Field  Committee  and  the  Bureau  Management  Team. 
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c.  methodology  of  the  technical  evaluation 

1.  Evaluation  Team 

The  following  Service  Center  team  was  selected  to  evaluate  the 
technical  (and  managerial)  aspects  of  the  Blueline: 

Greg  Graff  (Team  Leader),  Chief,  ALMRS-GIS  Project  Support  Staff 
Judy  Bright,  Systems  Implementation  Specialist,  ALMRS-GIS 
Project  Office 

Janet  Poorman,  Writer/Editor,  ALMRS-GIS  Project  Office 
Linnea  Probert , Systems  Analyst,  ALMRS-GIS  Project  Office 

2.  Approach 

The  team  interviewed  individuals  who  were  directly  involved  with  the 
design  and  development  of  the  Blueline.  Questions  developed  by  the 
team  for  these  interviews  reflected  the  stated  objectives  of  the 
Blueline  evaluation.  The  questions  were  based  on  the  Redline  evalua- 
tion findings,  expected  Blueline  results,  and  an  internal  technical 
report  written  by  Judy  Bright.  The  questions  were  divided  into  spe- 
cific areas — system  functionality,  development,  data,  and  management 
concerns.  Respondents  were  asked  questions  according  to  their  areas 
of  expertise  or  their  participation  or  involvement  during  the  Blueline. 
A separate  set  of  management  questions,  developed  by  the  team,  were 
directed  to  only  those  managers  who  participated  in  the  Blueline. 

After  completing  the  interviews,  the  team  compared  individual  responses 
to  determine  a consensus  of  findings.  If  seeming  discrepancies 
occurred  on  a particular  issue,  the  team  went  back  to  the  respondents 
for  clarification.  All  the  major  issues  addressed  in  this  evaluation 
have  consensus  except  the  development  of  system  specifications. 

D.  TECHNICAL  EVALUATION 

1.  Modules. 


The  purpose  of  this  section  of  the  evaluation  is  to  document  how  well 
the  Blueline  technology  could  meet  other  functional  requirements,  not 
to  determine  how  well  it  did  meet  the  functional  requirements  for  the 
APD  process.  That  issue  is  addressed  in  the  Users  portion  of  the 
evaluation. 

During  the  development  of  the  Blueline,  three  common,  generic  steps 
were  identified  for  processing  a case — Legal  Determination,  Conflict 
Determination,  and  Conflict  Mitigation.  As  long  as  the  appropriate 
data  is  available  in  the  data  base  and  serves  as  a basis  for  the 
modules,  this  division  will  lend  itself  to  most  Bureau  case  types. 

The  Blueline  system  of  modules  lends  itself  to  processing  cases  other 
than  APDs.  They  are  tools  that  may  have  Bureauwide  applicability. 

The  modular  concept  meets  the  needs  of  adjudication  and  mitigation, 
which  must  be  accomplished  for  all  cases  and,  therefore,  these  modules 
can  be  used  for  most  case  types. 
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The  modular  concept  eliminates  the  need  to  write  similar  types  of 
modules  for  all  case  types  and  require  only  those  modules  that  are 
case-specific.  By  designing  a system  in  modules,  maintenance  is 
easier  because  individual  modules  can  be  worked  on  without  bringing 
down  an  entire  system. 

Finding  1.  Generic  modules,  such  as  those  written  for  adjudication  and 
planned  for  mitigation,  will  accommodate  most  case  types. 

Using  both  the  alphanumeric  and  graphic  capabilities  along  with 
interactive  updates  gives  the  Field  a streamlined  process  with  which 
to  work.  The  graphics  capability  allows  the  user  to  see  a volume  of 
data  at  once  rather  than  going  through  case-by-case  to  determine 
legality  and  possible  conflict. 

In  addition,  the  modular  concept  lends  itself  to  easy  maintenance  while 
allowing  other  processes  to  be  added  to  the  system. 

Recommendation.  The  modular  concept  should  be  retained  when  designing  the 
Target  System.  The  Bureau  should  develop  the  modules  as  genetically 
as  possible  in  order  to  accommodate  common  requirements  across  the 
various  case  types.  After  the  generic  modules  are  designed, 
case-specific  modules  can  be  developed  which  accommodate  major 
functions.  This  strategy  requires  a flexible  data  base  design  so  data 
elements  can  be  added  and  queried  on  an  ad  hoc  basis  to  meet 
case-specific  requirements. 


Finding  2.  Present  right-of-way  descriptions  in  Case  Recordation  are 

described  as  aliquot  parts  rather  than  centerline  surveys.  As  such, 
alphanumeric  fields  present  a distorted  view  of  actual  right-of-way 
locations  (generally  along  section  boundaries).  Because  of  the  legal 
description  requirements,  the  Bureau  will  be  limited  in  its  ability  to 
display  rights-of-way  graphically. 

Recommendation.  Rights-of-way  will  have  to  be  digitized  to  alleviate 
distortion,  but  this  method  limits  the  benefits  of  the  automated 
system  because  of  data  quality  questions.  A Bureau  requirement  for 
centerline  surveys  for  rights-of-way  would  maximize  the  benefits  of 
automation  by  allowing  the  system  to  tie  the  right-of-way  to  a 
coordinate  point  and  by  graphically  displaying  the  right-of-way  in  its 
actual  location. 


2.  User  Support.  Since  the  Blueline  was  not  intended  to  test  operational 
use,  the  type  and  level  of  system  support  was  not  specifically 
identified  by  the  prototype. 

The  requirements  identified  by  the  Field  were  specific  in  terms  of  a 
need  for  an  easy-to-use  system.  These  requirements  were  met  with 
menus,  f ill-in-the-blank  entry  and  update  screens,  and  help  screens. 

Menus  and  screens  were  easy  to  use  and  understand  and  led  novices 
through  the  system. 

The  system  effectively  processed  an  APD  up  to  the  point  where 
development  had  stopped.  The  developed  modules  can  be  fairly  easily 
enhanced  to  pick  up  the  omitted  Blueline  pieces  of  the  APD  process. 
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General  Observations.  Good  user  interfaces  reduce  the  need  for  intensive 
and  lengthy  training.  These  kinds  of  interfaces  are  critical  for  user 
acceptance  because  they  reduce  the  fears  and  frustrations  inherent  to 
automation. 

The  users  of  the  Blueline  found  the  system  easy  to  operate.  They 
required  little  training  (1  to  1 1/2  days)  before  being  able  to  run 
the  application  comfortably.  This  probably  occurred  because  of 
intensive  user  and  programmer  communication  during  the  design  and 
development  of  the  Blueline,  and  because  the  developmental  hardware 
and  software  were  easy  to  use.  The  script  design  gave  the  programmers 
a good  idea  about  how  the  users  wanted  to  see  the  data  displayed. 

Finding  1.  While  the  Blueline  was  not  necessarily  intended  to  determine 
the  types  of  support  needed  for  maintenance  of  the  hardware  and 
software  in  the  Field,  this  need  was  strongly  indicated  by  the 
comments  (and  reinforced  by  management). 

Recommendation.  Most  individuals  interviewed  believed  that  some  type  of 
support  would  be  needed  in  each  office.  At  a minimum,  each  office 
would  need  a non-ADP  professional  who  was  trained  in  systems 
operation/ administration  as  a collateral  duty.  Many  specialists 
believed  that  a full  support  staff  would  be  necessary,  not  only  to 
operate  the  system,  but  also  to  train  and  encourage  users. 

The  evaluation  team  recommends  that  interim  test  sites  be  used  to 
further  evaluate  the  potential  needs  for  the  type  and  level  of  user 
support  that  will  be  required  for  the  Target  System. 


Finding  2.  Additional  types  of  user  interface  capabilities  should  be 
explored,  e.g.,  pull-down  windows  and  icons.  The  user  interfaces 
developed  for  the  Blueline  were  sufficient  for  demonstration  purposes. 

Recommendation.  The  evaluation  team  recommends  that  user  interfaces 
be  further  tested  and  reviewed.  Additionally,  users  should  be 
involved  with  the  programmers  and  analysts  during  the  design  and 
development  of  the  Target  System  to  ensure  adequate  user  interfaces. 

3 . Graphics  Requirements 

The  Blueline  met  the  graphic  requirements  of  the  Bureau  and  produced 
Master  Title  Plat-like  graphics.  The  Blueline  also  demonstrated  that 
previously  digitized  data  in  the  Bureau's  existing  GIS  could  be  ported 
over  to  the  Blueline  easily.  The  Blueline  graphics  were  also  integral 
in  editing  data  (see  Data  section,  item  7,  for  details). 

Recommendations . The  Blueline  demonstrated  that  current  technology  can 
meet  the  functional  graphics  requirements  of  the  Bureau;  therefore, 
these  requirements  should  be  included  in  the  Target  System  design. 

Finding  1.  The  Bureau's  current  manual  records  system  uses  MTPs  and  Use 
Plats  to  display  graphically  volumninous  alphanumeric  records  data. 
These  plats  help  users  to  perform  legal  and  conflict  determinations, 
and  decide  mitigation  procedures  more  easily. 
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Recommendation.  Any  new  system  needs  to  have  graphic  display  capabilities. 
Because  the  Blueline  demonstrated  that  existing  digitized  data  can  be 
used  with  record  and  coordinate  data  without  conversion  problems,  the 
need  to  collect  coordinate  data  for  resources  should  be  analyzed. 

4.  Query  Capability 


The  Blueline  Ad  Hoc  query  had  the  capability  to  retrieve  data  in  any 
format  requested.  BLM  has  over  1,000  different  case  types,  many  of 
which  require  differing  or  unique  data  sets  for  processing  cases.  An 
automated  system  will  need  to  either  take  into  account  all  the 
differing  data  requirements  for  the  1,000+  case  types  or  sort  ad  hoc 
queries  with  minimum  or  no  programming  requirements. 

Finding  1.  The  Blueline  demonstrated  that  an  RDBMS  can  meet  the  Bureau's 
requirement  for  ad  hoc  query  capability  by  using  SQL  commands. 
However,  the  Blueline,  as  constructed,  is  unable  to  display  data  sets 
that  have  not  had  screens  developed.  This  is  a limitation  caused  by 
the  user  interface,  not  by  the  RDBMS. 

Recommendat ion . As  the  contractor  starts  developing  user  interfaces,  BLM 
must  test  them  to  make  sure  that  the  interfaces  do  not  adversely 
affect  the  ad  hoc  query  functionality. 

5 . Development  of  System  Specifications 


Development  of  the  Blueline  entailed  an  in-depth  structured  analysis 
of  the  current  manual  process  for  an  APD;  analysis  of  the  first  level 
of  a future  automated  system;  specification  writing,  programming, 
testing;  and  the  actual  demonstration. 

Structured  analysis  was  used  to  analyze  the  current  manual  APD  process 
and  the  first  level  only  of  the  future  automated  process.  It  was  not 
completed  for  the  entire  future  automated  process.  The  analysis  was 
accomplished  by  a users  group  from  Farmington  and  analysts  from  the 
Service  Center. 

The  specifications  were  developed  by  a users  group  from  Albuquerque, 
Santa  Fe,  and  the  Service  Center  using  a script  that  depicted  the  APD 
process.  This  team  dropped  the  structured  analysis  in  favor  of  the 
script,  which  described  the  data  needed  and  the  method  of  display, 
because  they  felt  the  script  was  easier  to  understand.  Additionally, 
because  of  the  time  constraints,  the  specification  team  felt  the  script 
would  help  develop  system  specifications  more  quickly  than  structured 
analysis  would. 

Easier  is  not  always  better.  The  script  helped  the  programmers  see 
how  the  users  wanted  the  screen  to  appear,  but  integral  parts  of  the 
APD  process  were  overlooked.  The  effectiveness  of  the  specifications 
was  lost  because  the  programmers  were  told  how  to  code  rather  than 
what  was  actually  required.  Efficiency  was  lost  because  programmers 
continually  needed  the  users  to  explain  what  was  required. 
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General  Observations.  The  system  is  capable  of  processing  an  APD. 
Completion  of  the  Fluid  Surface,  Mitigation,  and  Consolidation 
modules,  along  with  recommended  changes  and  enhancements  to  the 
completed  modules,  will  give  the  field  a valuable  product  from  which 
the  Bureau  will  benefit  by  the  information  to  be  learned.  The 
specifications  required  the  system  to  be  programmed  in  modules, 
thereby  allowing  for  ease  of  maintenance  along  with  the  capability  of 
using  certain  modules,  such  as  adjudication  and  mitigation,  for  other 
case  types. 

Structured  analysis  provided  pictorial  and  definitive  views  of  each 
step  of  the  APD  process  along  with  data  requirements  now  accomplished 
in  Farmington.  It  was  considered  to  be  a tool  of  immeasurable  value 
in  analyzing  a process  as  it  followed  the  process  and  data  flow, 
step-by-step,  to  the  smallest  detail. 

By  working  with  users,  programmers  were  able  to  develop  a system  that 
met  user  needs. 

Finding  1.  Time  constraints  placed  on  the  analysis  and  specification 
writing  teams  caused  an  incomplete  analysis  and  an  incomplete 
specification  document. 

The  time  frame  for  writing  the  specifications  extended  well  beyond  the 
estimated  6 weeks;  actual  time  was  3 months. 

Recommendation.  Time  frames  can  be  met  with  the  proper  mix  of  technical 
and  functional  expertise.  The  team  concept  was  a necessary  component 
for  success.  Once  this  type  of  team  was  in  place,  the  Blueline  moved 
much  faster,  the  team  tended  to  stay  within  the  established  time 
frames,  and  the  team  produced  a quality  product.  This  expertise  could 
have  answered  the  technical  aspects  of  many  questions  concerning  what 
could  or  could  not  be  done  with  computers.  This  would  have  steered 
the  functional  group  in  the  right  direction. 


Finding  2.  An  incomplete  analysis  of  the  current  manual  process  as  well  as 
the  future  automated  system  made  writing  the  specifications  difficult. 
Important  steps  in  the  APD  process  were  left  out  such  as  analysis  of 
casing,  formations,  mud,  and  cement  programs  of  the  wells  within  a 
1-mile  radius  of  the  proposed  well. 

Most  specialists  believed  that  structured  analysis  was  a viable  method 
for  defining  the  current  manual  processes  and  future  automated 
processes  and  should  be  used  for  the  Target  effort.  One  specialist, 
however,  was  not  convinced  that  structured  analysis  would  give  the 
product  the  users  wanted  and  maintained  that  the  script  was  a good  way 
to  define  specifications. 

Recommendation.  The  evaluation  team  recommends  that  during  Target  develop- 
ment, one  analysis  methodology  should  be  used  throughout  the  entire 
process.  Mixing  methodologies  confused  both  the  users  and  the 
programmers,  resulting  in  a document  of  limited  use.  Structured 
analysis  appears  to  be  a good  methodology  for  developing  system 
specifications  because  it  works,  as  proven  by  systems  analysts  who 
commonly  use  this  type  of  method. 


Finding  3.  Because  the  specifications  given  to  the  programmers  defined  how 
the  users  wanted  the  system  designed  and  not  what  they  wanted  done, 
the  programmers  had  a difficult  time  developing  the  system  within  a 
functional  context.  Also,  the  specifications  were  based  on  proprietary 
knowledge,  so  the  programmers  had  to  work  very  closely  with  users  to 
determine  what  was  actually  needed  and  made  minimum  use  of  the 
specifications.  Although  the  system  met  the  user  needs,  it  required 
an  iterative  process  to  determine  system  requirements. 

Recommendation.  Specifications  must  concentrate  on  defining  what  should  be 
done  (functional  requirements)  and  must  clearly  describe  the  system 
and  data  overview.  Programmers  will  then  decide  how  it  should  be 
done,  based  on  their  expertise.  Technical  personnel  as  well  as  field 
users  must  be  an  integral  part  of  the  specification  writing  team  to 
ensure  a quality  document  for  the  programming  staff. 


Finding  4.  The  script  did  not  describe  all  the  functional  requirements, 
nor  did  it  match  specifications  to  requirements.  As  a result,  the 
system  specifications  were  not  understood  by  the  programmers.  There 
was  no  overall  explanation  about  how  various  pieces  were  to  fit 
together — no  systems  overview. 

The  programmers  had  a difficult  time  defining  relationships  between 
the  data  and  screens.  The  screens  depicted  how  the  users  wanted  the 
data  displayed,  but  did  not  indicate  what  the  data  would  be  used  for. 
Therefore,  the  programmers  designed  the  data  base  around  the  screens 
rather  than  the  screens  around  the  data  base. 

Recommendation.  In  defining  what  we  want  done,  commonalities  of  functions 
must  be  identified.  These  will  serve  as  a functional  test  criteria 
for  the  system  that  is  developed.  Then  an  overall  design  must  be 
developed  from  which  the  programmers  can  relate  individual  functions 
and  data.  Field  users  should  work  with  the  programmers  to  ensure  that 
the  system  meets  user  needs  and  to  clarify  any  questions  about  the 
specifications . 


Finding  5.  Management  changed  four  times  during  the  course  of  the  Project, 
thereby  creating  difficulties  for  those  working  on  the  Project.  Each 
manager  had  a different  viewpoint  and  focus  as  well  as  varying 
knowledge  of  the  whole. 

Recommendation.  Unless  absolutely  necessary,  managers  should  not  be 

changed  during  the  course  of  a project.  Retaining  the  same  manager 
will  ensure  continuity  and  focus  for  those  participating  in  the 
project . 
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6. 


Developmental  Hardware/ Software 


The  following  hardware  and  software  were  used  in  developing  the 
Blue line : 


Hardware 


Hewlett  Packard  (HP) 
9000/320/800  - m 


mainframe  computers 

former  mainframe  computer,  being  phased  out 
by  PRIME 


HP  560- 


Software 


UNIX 

ORACLE 

UNIRAS 

MATCH/MERGE 


PARCEL  GENERATOR  - 


operating  system  native  to  HP 

data  base  management  system  native  to  HP 

COTS  package  of  graphics  tools 

internal  software  package  that 

converts/integrates  records  data — status, 

case  recordation,  and  legal  land 

descriptions 

internal  software  package  used  to  graphic- 
ally display  alphanumeric  legal  land 
descriptions . 


In  addition  to  this  software,  custom  code  was  written  specifically  to 
accommodate  functions  needed  for  the  APD  (Generate  Geographic  Well 
Location,  Spacing,  and  Plot). 

The  data  base  was  built  through  the  use  of  the  operating  system, 

UNIX.  ORACLE  provided  the  capability  to  manipulate  and  store  the  data 
in  such  a way  as  to  afford  easy  and  quick  access. 

Both  the  hardware  and  the  software  used  in  the  Blueline  provided  good 
programming  tools  and  gave  utility  and  flexibility  to  the  programmers 
in  meeting  the  requirements  of  the  system.  The  Match/Merge  program 
alleviated  the  need  for  the  programmers  to  take  data  from  the 
individual  data  bases  and  to  convert  the  data  to  a standard  format  in 
order  to  have  a single  data  base. 

These  tools  enabled  the  programmers  to  write  code  faster  and,  since 
they  are  programmer-friendly,  a user-friendly  system  was  quickly  and 
easily  built. 

Both  the  hardware  and  the  software  were  easy  for  the  programmers  to 
use.  The  users  needed  very  little  training — a maximum  of  a day  and  a 
half — to  become  familiar  with  the  hardware  and  software  products. 

General  Observations. 

a.  Hardware.  Even  with  the  learning  curve,  the  programmers 

considered  the  HP  9000/320  to  be  a good  development  tool,  with 
especially  good  features  for  use  in  developing  programs. 
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HP  support  for  the  320,  from  sales  and  service  locally  and  via  the 
Hotline,  was  good.  According  to  the  Systems  Administrator,  Dennis 
Colarelli,  the  equipment  was  easy  to  install  and  maintain.  The 
hardware  is  considered  reliable  and  performed  well  considering  the 
320  was  not  designed  to  handle  the  number  of  users  the  project  had 
on  the  system  at  one  time. 

Some  development  was  done  on  the  PRIME  using  "C"  computer  language. 
Because  "C"  was  used,  conversion  to  the  HP  was  accomplished  with  no 
difficulty.  ("C"  ports  to  other  computers  easily.) 

Time  was  lost  when  the  process  was  transferred  to  the  560  and  then 
back  to  the  320.  Originally,  the  560  was  to  go  to  Farmington  at 
the  APD  test  site,  but  it  was  not  operational  when  the  programming 
began.  The  APD  package  started  on  the  320,  but  was  ported  to  the 
560,  which  seemed  to  be  operational.  This  action  created  many 
problems  because  the  560  was  not  fully  supported  by  Hewlett-Packard. 
Due  to  this  lack  of  support,  the  decision  was  made  that  the  560 
would  not  go  to  Farmington,  and  the  package  was  ported  back  to  the 
320.  Most  specialists  believed  much  of  the  porting  problems 
encountered  with  the  Blueline  could  have  been  avoided  had  the 
system  been  maintained  on  only  one  set  of  hardware. 

b.  Software.  COTS  packages  met  the  basic  functional  requirements  and 
saved  development  time.  Of  the  necessary  custom  code,  most  was 
required  for  specific  user  interfaces.  Few,  if  any,  COTS  packages 
will  accommodate  all  the  specific  needs  of  the  Bureau.  However, 
custom  coding  is  easier  to  develop  with  these  packages;  large 
amounts  of  time  can  be  saved  when  user  interfaces,  such  as  screens, 
menus,  and  help  screens,  are  being  developed. 

UNIX 


UNIX  is  programmer-friendly,  has  good  development  tools,  and  has 
good  documentation.  The  only  drawback  to  UNIX  seems  to  be  its  lack 
of  the  necessary  security  protocols. 

ORACLE 

The  ORACLE  RDBMS  has  good  development  tools  as  well  as  support  from 
the  ORACLE  company . 

Some  problems  occurred  as  each  new  revision  of  ORACLE  was  received 
and  put  into  place.  Not  all  functions  were  available  on  each 
revision,  thus  causing  some  problems  with  the  programs  that  had 
already  been  developed.  There  also  seemed  to  be  a communica- 
tion problem  as  everyone  working  with  ORACLE  was  not  aware  when  a 
revision  was  being  installed.  Documentation  for  ORACLE  is  hard  to 
follow,  creating  problems  for  the  programmers.  ORACLE  does  not 
work  well  in  a distributed  environment  because  of  limitations  on 
multiple  access  to  the  same  data.  However,  even  given  these 
limitations,  the  system  met  all  the  requirements  of  the  user, 
including  graphic  display  of  alphanumeric  data. 
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UNIRAS 


UNIRAS  is  flexible,  fast,  and  easy-to-use.  Documentation  is  good, 
and  this  package  also  works  on  many  different  devices.  However, 
this  software  does  not  have  the  analytical  tools  necessary  for  a 
geographic  information  system  (GIS).  It  requires  the  programmer 
to  use  FORTRAN  binding  instead  of  "C,"  which  limits  its  utility 
and  portability.  Also,  a plot  cannot  be  interrupted  once  it  has 
started.  There  is  a problem  with  building  processes,  as  UNIRAS 
links  all  devices  in  code.  This  creates  delays  in  execution. 

MATCH/MERGE 


The  Match/Merge  software  is  capable  of  integrating,  verifying, 
correcting,  and  matching  record,  resource,  coordinate,  and  PI  data 
to  produce  graphics  and  alphanumeric  data.  The  end  product  was  a 
merged  file  of  Case  Recordation  and  Status  that  had  been  matched 
against  the  Legal  Land  Description  (LLD).  This  product  gave  an 
error  listing  of  unmatched  data,  which  was  edited  by  New  Mexico, 
and  provided  new  edit  capabilities,  thus  raising  the  quality  of 
the  data. 

The  assumption  was  made  that  conversion  (Match/Merge)  of  the 
Record  Data — Status,  Case  Recordation,  and  Legal  Land  Description 
(LLD) — would  take  approximately  6 weeks.  The  actual  conversion 
took  6 months,  due  to  the  following: 

° Data  formats  varied; 

° Data  was  collected  inconsistently,  with  no  clear-cut 
understanding  of  what  was  needed; 

° Data,  such  as  Known  Geologic  Structures,  Communiti- 

zation  Agreements,  and  Unitized  Agreements,  was  missing; 

° More  data  was  being  processed  than  just  that  for  the  nine 
townships  in  Farmington; 

° Program  testing  took  more  time  than  anticipated. 

The  Match/Merge  programs  significantly  reduced,  by  about 
two-thirds,  the  amount  of  time  needed  to  convert  data  from  the 
various  data  bases. 

note  I These  findings  are  included  for  information  only.  No 
real  recommendations  are  made  because  these  will  be  determined  by 
specifications  during  the  design/development  of  the  Target  System. 

7 . Data  and  Developmental  Data  Base 

One  of  the  primary  objectives  set  for  the  Blueline  was  to  demonstrate 
the  integration  of  coordinate,  record,  and  resource  data  using 
developmental  hardware  and  software. 

Records  data  was  collected  from  the  Case  Recordation  (CR),  automated 
Status  flat  files,  and  LLD  flat  files.  The  Case  Recordation  data  was 
converted  to  match  the  Status  format.  Then  the  CR  and  Status  data 
were  run  through  the  Match/Merge  program  and  edited  against  the  LLD 
file,  producing  a flat  file  called  Status.  However,  the  Match/Merge 
program  did  not  convert  action  codes. 
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The  data  base  was  structured  using  the  operating  system,  UNIX.  ORACLE 
provided  the  capability  of  manipulating  the  data  and  storing  the  data 
in  such  a way  as  to  afford  easy  and  quick  access. 

Resource  data  previously  digitized  and  used  on  the  Data  General  was 
ported  across  in  a flat  file  to  the  HP  to  include  paleontological, 
eagle  habitat,  coordinate  data,  and  Petroleum  Information  (PI)  well 
history  data  needed  for  the  Blueline. 

These  data  types/themes/sets  ported  to  the  HP  with  no  problems.  The 
PI  well  data  was  alphanumeric  and  was  entered  into  ORACLE-structured 
tables.  The  Blueline  had  limited  numbers  of  resource  themes  since  the 
Redline  had  demonstrated  these  capabilities.  The  Blueline  did  just 
enough  to  demonstrate  data  base  capabilities. 

Data  was  easy  and  fast  to  access  due  to  ORACLE  structure  and  indexing 
capabilities.  This  RDBMS  made  processing  the  APD  much  more  efficient. 
Integration  of  the  various  data  sets  into  one  data  base  made  program- 
ming easier.  It  afforded  easier  and  speedier  access  for  the  user  to 
query  and  manipulate  the  data  to  suit  the  varied  needs  of  the  Bureau. 

The  data  base  was  more  efficient  on  the  Blueline  because  various  data 
sets  could  be  selected  and  displayed  rapidly  and  easily.  The  current 
manual  process  requires  the  user  to  gather  information  from  Case 
Recordation,  Bond  and  Surety,  and  multiple  hardcopy  file  systems. 

General  Observations.  Having  the  data  in  a common  data  base  made  program- 
ming easier  and  allowed  users  more  flexibility  to  manipulate  and  use 
the  data. 

An  integrated  data  base  gives  the  Field  the  capability  to  access, 
update,  manipulate,  and  query  easily  and  fast. 

The  programs  written  to  convert  the  various  data  sets  (Match/Merge) 
and  to  graphically  display  the  data  sets  (Parcel  Generator)  afforded 
the  Blueline  numerous  edit  capabilities,  such  as  visually  showing 
duplicate  entries  and  overlapping  cases.  Edits  like  these  are 
invaluable  to  the  Bureau,  but  also  point  to  the  need  for  data 
standards  and  consistency. 

Finding  1.  Quality  data  must  be  a primary  concern  for  the  Bureau.  The 
demonstration  provided  the  means  to  integrate  and  use  record, 
resource,  and  coordinate  information,  but  emphasized  the  need  for 
accuracy.  The  field  users  primarily  focused  on  errors  in  the  data, 
not  on  whether  the  Blueline  adequately  demonstrated  the  requirements 
requested  for  the  APD  process.  Data  quality  is  inherent  to  the 
success  of  any  system. 

Recommendation.  Data  management  should  be  a primary  and  up-front  concern. 
Both  for  the  Interim  and  Target  systems,  the  Bureau  should  identify 
data  needed,  collection  procedures,  entry  format,  and  maintenance 
procedures  and  put  them  into  place. 

As  each  new  quality  control  process  is  created,  it  should  be  put  in 
use  for  all  the  States,  thus  providing  higher  quality  data  both  for 
the  Interim  and  the  Target  systems. 
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Finding  2.  Even  with  an  RDBMS  and  various  software  packages,  no  real 

mechanisms  are  in  place  to  convert  data  structure  and  increase  quality 
control  for  resource  data  or  existing  GIS  data. 

Recommendation ♦ Resource  data  is  an  essential  part  of  case  processing, 
not  only  for  APDs  but  also  for  all  other  Bureau  cases.  An  intense 
effort  to  gather  this  resource  information  should  begin  as  soon  as 
possible.  This  plan  should  include  standardized  formats  and 
consistency  controls. 


Finding  3.  The  data  base  structure  for  the  Blueline  was  developed  when  the 
screen  displays  were  developed.  Because  of  this,  the  data  base 
structure  is  tied  to  the  screens,  rather  than  the  screens  to  the  data 
base  structure.  This  will  make  redesigning  the  data  base  structure 
difficult  when  we  try  to  accommodate  different  case  types  and  increase 
efficiency  and  flexibility.  However,  even  with  the  current  structure, 
ORACLE  does  give  the  flexibility  to  change  data  tables  so  we  can 
accommodate  other  case  types.  We  just  would  not  be  able  to  maximize 
efficiency . 

Recommendation.  The  data  base  structure  should  be  redesigned  to  better 
accommodate  the  relationships  of  the  data  as  well  as  the  cases 
processed  by  the  Bureau. 

The  data  base  for  the  Target  System  should  be  designed  before  the 
individual  applications  are  developed  to  achieve  maximum  flexibility. 

In  its  simplest  terms,  the  system  is  merely  one  large  data  base.  We 
must  concentrate  our  efforts  on  the  data  base  design.  The  Blueline 
proved  that  individual  applications  are  fairly  simple  to  develop,  but 
the  data  base  was  designed  to  fit  one  type  of  application.  The  Target 
data  base  must  be  designed  to  accommodate  all  applications. 


Finding  4.  We  must  continue  to  collect  coordinate  data  for  the  system  so 
we  can  achieve  the  benefits  of  automation.  Geocoordinate  data  was 
needed  to  tie  data  sets  to  geographically  correct  points  on  the  earth. 
This  tie  is  critical  to  a land  management  agency  because  managers  must 
make  decisions  about  discrete,  real  pieces  of  land,  and  the  data  on 
which  these  decisions  are  made  must  be  tied  to  those  pieces  of  land. 

Graphics  are  a primary  tool  in  this  decision  process  because  overlays 
of  multiple  themes  are  used  to  determine  conflicts.  All  the  data  must 
be  spatially  related  to  a precise  point  on  the  earth  in  order  to 
relate  separate  data  sets  for  overlays  and  conflict  determination/ 
resolution. 

Recommendation.  The  Bureau  must  continue  its  coordinate  data  collection 
efforts  so  graphic  displays  will  be  geographically  correct  and 
spatially  oriented  to  ensure  quality  data  for  the  decisionmakers. 
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E.  MANAGEMENT  OBSERVATIONS  AND  CONCERNS 


1.  Purpose 


The  technical  team  interviewed  field  managers  involved  with  the 
Blueline  to  determine  their  observations  and  concerns.  Many  of  the 
concerns  fell  outside  the  scope  of  the  Blueline  evaluation,  but  we 
believe  project  management  should  review  them  and  develop  strategies 
to  address  them. 

Management  observations  and  concerns  are  divided  into  the  following 
two  groups — Blueline  Specific  and  Automation  in  General: 

2 . Blueline  Specific  Observations/Concerns 


a.  An  automated  LIS  is  a valid  concept  for  the  Bureau  in  its  land 
management  responsibilities.  For  the  Bureau  to  perform  its  land 
managing  activities  more  effectively,  it  must  make  full  use  of  the 
capabilities  that  automation  can  provide. 

b.  Structured  analysis  is  a valuable  tool  that  should  be  used 
throughout  the  Bureau  to  analyze  both  manual  and  automated 
processes  and  functions.  The  analysis  should  be  applied  to 
offices  as  well  as  to  discrete  work  elements  within  the  offices 
because  it  readily  identifies  duplication  and  indicates  areas  that 
could  be  streamlined  to  make  a more  effective  and  efficient 
organization.  As  a logical  spinoff  from  the  Blueline,  some  Field 
Offices  are  already  successfully  restructuring  their  organizational 
tables  and  processes,  based  on  this  methodology. 

c.  As  modules  are  developed,  they  should  be  thoroughly  Field-tested 
to  verify  functionality.  This  process  would  give  the  Bureau 
feedback  in  systems  development  and  would  help  familiarize  users 
with  automated  tools.  (The  more  familiar  users  are  with  a system, 
the  more  receptive  they  will  be.) 

d.  ADP  support  staffs  will  be  needed,  at  least  initially,  to  operate 
and  repair  equipment  and  help  train  users  in  ADP  applications. 

New  Mexico  will  be  training  non-ADP  personnel  in  systems 
operation/administration  to  determine  if  this  is  a feasible 
strategy  to  meet  their  need  for  ADP  support.  These  individuals 
will  train  others  to  use  automation  capabilities.  They  will  also 
work  with  managers  to  show  how  automation  can  be  used  in  the 
analysis /decision  process. 

e.  The  ADP  procurement  process  hinders  the  capability  of  field 
offices  to  purchase  and  install  ADP  hardware  and  software. 
Farmington  had  to  go  through  the  District  Office,  State  Office, 
Service  Center,  and  the  Washington  Office  to  purchase  items. 

In  New  Mexico,  all  requisitions  for  ADP  equipment  have  to  be 
completed  by  June  15  if  funds  are  to  be  committed  before  the  end 
of  the  fiscal  year.  Changing  technology  in  automation  is  less  pre- 
dictable than  other  types  of  procurement  needs.  An  office  cannot 
always  predict  what  will  be  needed  1,  5,  or  10  years  from  now. 
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To  bypass  this  system,  Farmington  went  directly  to  the  Service 
Center  to  purchase  software  packages  because  of  an  immediate 
need.  Had  Farmington  gone  through  the  normal  procurement  process, 
software  would  have  taken  months  instead  of  weeks  to  procure.  As 
it  was,  Farmington  left  ^40,000  on  the  table  at  the  end  of  the 
fiscal  year  because  they  could  not  get  the  paperwork  through  for  a 
power  conditioner.  The  Bureau  is  again  funding  it  for  this  year. 
As  we  implement  the  Target  System,  the  Bureau  must  reevaluate  its 
procurement  policies  for  ADP  equipment. 

3.  General  Automation  Recommendations 


a.  Automation  will  change  the  character  of  the  way  the  Bureau  does 
business,  but  the  impacts  have  yet  to  be  fully  analyzed.  Automa- 
tion will  give  the  Bureau  the  capability  to  further  decentralize 
decisionmaking  as  more  and  better  data  becomes  available  at  all 
levels  of  the  organization.  However,  where  data  should  reside  or 
who  should  be  authorized  to  change  the  data  has  not  been  deter- 
mined. Answers  to  these  questions  could  have  a dramatic  impact  on 
the  organizational  structures  and  the  roles  and  responsibilities 
of  individual  offices.  These  questions  may  be  answered  through 
further  testing  and  documentation  of  the  Bureau's  test  sites, 
including  the  creative  spinoffs  (secondary  capabilities)  that  are 
occurring.  For  example,  Farmington  is  already  in  the  process  of 
restructuring  their  office  and  have  analyzed  potential  shifting  of 
responsibilities  for  other  offices  within  the  State.  They  have 
further  analyzed  job  structures  and  training  needs  so  their  own 
staffs  will  be  prepared  for  automation.  Thorough  evaluations 
documenting  what  is  being  done  at  this  test  site  and  others  are 
critical  if  the  Bureau  is  to  deal  effectively  with  the  issues. 

b.  Data  collection  efforts  have  focused  on  records  and  coordinate 
data,  but  little  has  been  done  in  the  way  of  resource  data.  Over 
the  years.  Bureau  offices  have  collected  resource  data  in  a multi- 
tude of  ways.  Criteria  have  also  varied  substantially  according 
to  individual  office  needs.  In  addition,  many  specialists  have 
been  hesitant  to  share  their  knowledge  and  data  with  others.  Yet, 
to  have  a functioning  LIS,  the  Bureau  must  have  resource  data. 

All  cases  must  determine  resource  conflicts  and  mitigation 
procedures  before  they  can  be  authorized.  At  present,  the  Bureau 
has  no  coherent  strategy  for  dealing  with  the  various  individual 
resource  data  needs.  Bureau  management  must  start  developing  an 
overall  strategy  for  the  LIS  and,  in  it,  the  resource  data  issue 
must  be  addressed. 

c.  Staffs  must  be  prepared  for  automation  when  it  arrives. 

Strategies  for  training  and  user  awareness/acceptance  must  be 
developed  before  the  Target  capabilities  are  put  in  place. 
Otherwise,  we  run  a risk  of  user  rejection.  As  an  adjunct  to  this 
issue,  we  must  also  determine  how  we  can  best  assist  and  prepare 
the  user. 
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The  Blueline  has  helped  clarify  the  issue  of  whether  the  Bureau  is 
automating  its  business  or  merely  automating  its  existing 
processes.  Through  the  prototype  efforts,  several  duplicative, 
unnecessary,  and  costly  processes  have  been  identified  and 
eliminated.  We  have  found  that  automation  will  not  change  what  we 
do — only  how  we  will  do  it.  As  the  character  of  the  Bureau's  work 
evolves  and  changes,  the  Project  Office  must  focus  on  what  should 
be  automated  rather  than  on  how  well  automated  capabilities  will 
be  used.  It  is  up  to  Bureau  management  to  concentrate  on  how  to 
use  automation  most  effectively. 
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BLUELINE  DEMONSTRATION  --  FARMINGTON  DEMONSTRATION  PROJECT 
USERS  GROUP  EVALUATION  REPORT 


Introduction 


A.  Purpose  of  the  Users  Evaluation 

This  part  of  the  evaluation  was  conducted  in  order  to  give  the  BLM  an 
indication  of  the  success  of  the  Blueline  Phase  of  the  Farmington 
Demonstration  Project  (FDP)  from  the  users  perspective.  In  other 
words,  regardless  of  the  technical  success  of  the  project,  we  need  to 
know  how  well  the  user  requirements  were  met,  and  whether  the 
identified  user  requirements  were  applicable  and  useful  Bureauwide. 

As  the  Blueline  was  originally  conceived  for  the  FDP,  the  intent  was 
to  derive  technical  specifications  for  inclusion  in  the  Request  for 
Proposals  (RFP)  for  the  target  Land  Information  System  (LIS).  In  so 
doing,  an  integral  and  far  more  encompassing  issue  is  the  question  of 
whether  or  not  the  Blueline  succeeded  in  meeting  the  user  needs 
identified  by  the  Farmington  resource  specialists  at  the  outset  of  the 
project  Without  this  "reality  check",  the  technical  results  are 
valueless. 

Specifically,  the  users  group  looked  at: 

1.  How  well  the  demonstration  system  performed  the  processing 
functions  of  an  APD  as  identified  by  the  resource  specialists 
in  Farmington;  as  well  as  how  it  could  perform  the  processing 
functions  of  an  APD  in  other  offices  in  BLM,  given  the  typical 
procedural  differences  throughout  the  agency. 

2.  IVhat  the  benefits  and  problems  of  using  the  demonstration 
system  are  as  perceived  by  the  evaluation  team. 

3.  What  changes  should  be  made  to  improve  the  demonstration 
system  when  it  is  made  operational,  and  what  should  be  looked 
at  in  designing  future  systems,  from  the  users  perspective. 

The  user  group  was  careful  to  avoid  addressing  technical  automation 
questions  that  are  being  examined  by  a technical  group  in  the  Blueline 
evaluation  team.  However,  as  with  any  other  team  effort,  the 
distinctions  between  the  two  evaluation  groups  may  get  blurred. 

Figure  1 is  a schematic  showing  the  focus  of  the  two  different 
evaluation  groups  relative  to  the  sequenced  steps  of  the  development 
of  the  Blueline.  Both  evaluations  are  necessary  prior  to  making  the 
demonstration  system  operational  and  completing  the  RFP  specifications 
for  the  target  LIS. 
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FIGURE  1 


FARMINGTON  BLUELINE  DEMONSTRATION  EVALUATION 

THE  USER  GROUP  IS  EVALUATING  THE  DEMONSTRATION  SYSTEM  AGAINST  THE  USER  REQUIREMENTS 
THE  TECHNICAL  GROUP  IS  EVALUATING  THE  SYSTEM  SPECIFICATIONS  AND  DESIGN  BOTH 
EVALUATIONS  ARE  NEEDED  PRIOR  TO  MAKING  THE  SYSTEM  OPERATIONAL  AND  COMPLETING  THE 
RFP  SPECIFICATIONS  FOR  THE  TARGET  LI.S. 
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B.  Scope  of  the  Users  Evaluation 


This  evaluation  was  extremely  narrow  in  scope  for  a number  of 
reasons.  The  fact  that  the  Blueline  demonstration  system  itself  only 
examined  the  APD  process  from  receipt  to  approval,  necessarily 
limited  the  scope  of  the  analysis  to  only  that  narrow  procedural 
activity.  Clearly,  the  Bureau  has  a wide  range  of  procedural 
activities  that  could  have  been  similarly  automated  to  demonstrate 
the  linkage  and  interrelationships  of  records,  resources  and 
coordinate  data,  however,  only  the  APD  process  was  examined.  Even 
such  actions  as  the  right-of-way  for  the  road  leading  to  the  well  pad 
examined  in  the  APD  was  not  included  in  this  package,  even  though  it 
is  perceived  as  an  integral  APD  processing  step  by  many  Bureau 
offices.  Analysis  and  monitoring  activities  of  the  well  following 
APD  approval  were  also  not  included  in  the  package  and  were  therefore 
not  examined. 

To  assure  that  the  interrelationships  to  these  and  other  critical 
automatable  actions  are  not  forgotten  in  future  system  development 
actions,  the  user  group  has  tried  to  identify  important  linkages. 
These  and  other  comments  beyond  the  scope  of  the  evaluation  have  been 
included  in  Part  VI  of  this  report. 

Another  factor  that  limited  the  scope  of  the  user  evaluation  is  the 
fact  that  only  two  of  the  five  proposed  analysis  modules  in  the  APD 
package  were  completed  by  DSC  for  demonstration.  Only  the 
Adjudication  Module  and  the  Drilling  and  Production  Module  were 
completed  to  the  point  of  system  demonstration.  The  Fluid  Surface 
Management,  Mitigation  and  Consolidation  Modules  were  completed  as 
far  as  the  system  specifications  step  but  were  unavailable  for 
demonstration.  While  the  two  completed  modules  gave  the  evaluation 
team  a taste  for  things  to  come,  the  complete  evaluation  of  the 
system  from  the  users  perspective  is  impossible. 

The  team  has  therefore  looked  closely  at  the  two  completed  modules 
and  has  examined  the  system  specifications  of  the  remaining  modules 
to  get  a feel  for  the  anticipated  total  system.  There  are  inherently 
some  problems  with  such  an  analysis,  and  the  team  agreed  that  a users 
evaluation  might  be  premature  at  this  time.  However,  it  was  felt 
that  sufficient  work  had  been  completed  on  the  package  to  assess  the 
process  used  by  DSC  to  develop  the  APD  processing  system,  and  the 
evaluation  team  was  asked  to  proceed  given  this  limited  scope. 

Lastly,  the  scope  of  the  evaluation  was  constrained  by  time  and 
energy.  It  was  agreed  to  keep  this  study  reasonable  in  terms  of 
manpower,  money  and  time  expended  for  the  analysis.  A small  team 
with  short  deadlines  was  asked  to  take  a "quick  and  dirty"  look  at 
the  demonstration  and  offer  their  observations.  The  methodology  used 
in  the  evaluation  is  described  in  more  detail  in  the  next  section. 
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C.  Methodology  of  the  Users  Evaluation 


1.  Evaluation  Team.  A small  evaluation  team  was  selected  to 
represent  a good  cross-section  of  the  resource  specialists 
involved  in  the  APD  process,  as  well  as  a good  geographic  mix  to 
offer  different  perspectives  from  different  offices.  The 
following  individuals  were  Included  on  the  team: 

John  Singlaub  (Team  Leader) , Area  Manager,  Grand  Junction 
Resource  Area,  Colorado. 

Jamie  Connell  Petroleum  Engineer,  Miles  City  District  Office, 
Montana. 

Clare  Miller,  Environmental  Scientist,  Great  Divide  Resource 
Area  Rawlins.  Wyoming. 

Jim  Salas,  Geologist,  Roswell  District  Office,  New  Mexico. 

Linda  Slone,  Land  Law  Examiner,  Platte  River  Resource  Area, 
Casper,  Wyoming. 

2.  Approach.  The  team  met  in  Denver  and  were  briefed  on  the 
background  purpose  and  objectives  of  the  Farmington 
Demonstration  Project  and  the  Blueline  phase.  Greg  Graff  (DSC), 
John  Foster  (DSC),  Sam  Montgomery  (Farmington  R.A.),  and  Jeff 
Nighbert  (New  Mexico  S.O.)  brought  the  team  up  to  date  on  the  FDP 
and  the  process  used  to  arrive  at  the  demonstration  system.  Judy 
Bright  (DSC)  gave  the  team  a detailed  demonstration  of  the 
completed  modules. 

The  team  members  then  had  the  opportunity  to  operate  the  system 
themselves  to  simulate  actual  use.  This  opportunity  to  use  the 
system  hands-on  served  as  a typical  (although  quite  brief) 
production  test  for  the  APD  modules.  This  would  normally  be  a 
first  step  in  getting  a production  system  operational  for  field 
use.  In  the  course  of  the  test,  several  idiosyncracies  and  bugs 
appeared  (as  would  be  normally  expected)  — unintelligible  error 
messages  appeared  the  system  went  down,  non-normal  user  commands 
were  confronted,  etc.  - resulting  in  some  discouragement  by  team 
members  Where  relevant  to  the  evaluation  these  observations 
have  been  included  in  the  report. 

The  team  then  reviewed  the  system  specifications  for  all  modules 
and  discussed  them  with  New  Mexico  and  DSC  personnel  for 
clarification.  The  team  also  consulted  with  their  professional 
counterparts  elsewhere  in  the  Bureau  on  procedural  differences 
found  in  other  offices. 

After  agreeing  on  an  outline  for  the  final  report,  the  team  then 
documented  the  benefits  and  problems  of  the  system  as  they 
perceived  them,  and  proposed  recommendations  for  changes  or 
improvements.  The  total  elapsed  time  for  the  evaluation  was  less 
than  one  month,  including  preparation  of  the  final  report. 
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D.  Summary  of  Results/Overall  Conclusloas 


The  user  team  was  clearly  impressed  by  the  significant  strides  made 
by  the  Bureau  in  automation.  The  development  of  macros  and  the  use 
of  data  base  management  systems  to  access  different  data  bases  makes 
for  a friendly  user  environment  to  process  a complex  action. 

The  team  felt  that  this  is  exactly  the  kind  of  development  effort  on 
which  the  Service  Center  should  be  focusing  their  time-  The 
technology  is  today's  technology  and  the  systems  are  available  (or 
will  be  soon)  in  each  Bureau  office.  Benefits  to  the  field  in 
implementing  Bureau  programs  is  most  evident  in  this  kind  of 
application.  Plus,  by  introducing  Bureau  employees  to  automated 
processes  with  clear  benefits  to  them,  we  have  gained  the  early 
support  of  users  for  future  implementation  of  target  systems. 

The  demonstration  system,  as  developed  so  far  and  envisioned  for 
completion,  makes  excellent  use  of  spatial  graphics,  a critical  tool 
for  this  and  most  other  resource  management  activities.  As  future 
systems  are  developed  access  to  spatial  graphics  data  bases  and 
analytical  methods  must  be  included.  Further,  access  to  related 
alphanumeric  data  bases  including  records  and  resource  data,  must  be 
made  easily  accessible  to  resource  specialists  in  the  vast  majority 
of  applications.  The  "invisibility”  to  the  user  of  accessing  these 
other  data  bases  in  the  demonstration  was  a significant  breakthrough 
for  the  Blueline  effort. 

The  team  sees  the  potential  for  systems  such  as  these  to  provide  the 
opportunity  for  resource  professionals  to  spend  more  time  doing  the 
professional  work  they  were  hired  for,  and  less  time  on  paper 
chases.  While  we  were  unable  to  quantify  the  potential  time  savings, 
it  is  perceived  that  changes  in  work  flow  and  skills  utilization 
could  accrue  significant  benefits  to  the  agency. 

One  problem  observed  by  this  team  dealt  with  the  apparent 
inconsistency  in  the  way  the  same  task  is  carried  out  by  different 
offices  within  the  Bureau.  Applicable  handbooks  and  manuals  outline 
the  general  requirements,  but  individual  offices  accomplish  the 
mission  by  very  different  methods.  Minor  differences  occur  such  as 
varying  checklists  and  data  entry  forms  Major  difference  are 
encountered  when  reviewing  the  distribution  of  responsibilties  among 
the  resource  specialists  involved  in  a common  process. 

As  automated  systems  are  developed,  these  discrepencies  between 
offices  are  quickly  uncovered.  To  gain  acceptability  in  the  field, 
each  automated  process  would  have  to  include  built-in  flexibility  to 
account  for  differences  between  offices.  On  the  other  hand,  however, 
the  Bureau  may  want  to  take  advantage  of  the  switch  to  automation  to 
build  in  consistency  and  standardization  of  processes  where  clear 
advantages  to  the  program  or  agency  would  accrue.  This  would  require 
BLM  managers  to  apply  the  same  logic  required  to  develop  computer 
programs  to  their  resource  programs. 
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Another  issue  related  to  this  program  consistency  problem  is  the 
realization  that  as  we  automate  processes  in  the  BLM,  flaws  are 
discovered  in  the  way  we  are  currently  doing  business.  These 
problems  include  such  things  as  performing  duplicate  work, 
maintaining  multiple  records  or  files,  bottlenecks  in  work  flow, 
etc. 

Detailed  evaluations  of  job  functions  are  required  in  order  to 
automate  work  steps.  As  these  evaluations  uncover  inefficient  or 
inappropriate  work  flow  or  processes,  BLM  should  give  serious 
consideration  to  changing  the  way  we  do  business.  This  analysis  and 
possible  restructuring  of  individual  jobs  or  work  processes  should  be 
beneficial  to  the  agency  as  a whole. 

Since  the  Fluid  Surface  Management,  Mitigation,  and  Consolidation 
Modules  were  not  completed  for  the  Blueline  demonstration, 
consideration  should  be  given  to  a detailed  user  evaluation  of  these 
remaining  modules  prior  to  implementation. 

It  was  difficult  to  understand  why  all  five  modules  had  not  been 
completed  given  the  time  frames  available  to  the  Service  Center.  It 
is  recommended  that  DSC  examine  their  programming  efficiencies  to 
determine  why  the  whole  system  was  not  completed  for  the 
demonstration.  The  time,  effort  and  cost  that  obviously  went  into 
the  Blueline  demonstration  should  have  yielded  more  complete 
results.  As  the  Bureau  moves  toward  implementing  these  time-saving 
automated  efforts  on  a production  basis,  we  must  be  sure  we  are  doing 
so  with  an  efficient  staff  and  cost  effective  process. 

As  the  team  looked  at  the  system  design  completed  thus  far,  numerous 
problems  were  identified.  Due  to  the  constraints  of  the  evaluation, 
it  is  likely  that  additional  refinements  or  enhancements  could  be 
identified  with  further  user  evaluation.  The  problems  Identified  in 
this  report  and  those  still  to  be  discovered  must  be  resolved  before 
making  the  demonstration  system  operational. 

As  future  macros  are  developed,  BLM  needs  to  standardize  the 
procedures  used  to  establish,  test  and  implement  automated  systems. 
User  teams  should  be  brought  on  early  to  identify  user  requirements 
(as  they  were  for  the  Blueline)  for  the  programmers,  and  to  perform 
user  evaluations  prior  to  making  the  systems  operational.  It  is  left 
to  the  technical  team  to  determine  the  success  of  the  process  used  in 
the  Blueline  demonstration  system  development. 
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II.  Overall  System 


This  section  includes  our  observations  on  the  overall  system  as  completed 
for  the  Adjudicative  and  Drilling  and  Production  Modules,  and  the  system 
design  as  anticipated  for  the  remaining  modules.  We  believe  that  the 
full  APD  processing  system  should  be  evaluated  prior  to  implementation  as 
a production  system  in  the  field. 

A.  System  Design 

1.  Ease  of  use  / User  interface.  The  system  as  a whole  is  easy  to 
enter  and  follow.  The  menus  and  limited  use  of  help  screens 
provides  a user  friendly  environment. 

User  access  is  an  important  aspect  of  the  system.  It  is  necessary 
that  the  use  of  security  codes  within  the  system  remain  flexible. 
Security  codes,  used  to  determine  "read"  and  "read/write 
authority,  are  dependent  upon  management  decisions  in  each 
individual  office.  The  system  must  incorporate  a user  access 
system  that  is  versatile  enough  to  allow  for  these  changes  and 
differences  among  offices. 

2.  Effectiveness.  The  system  as  defined  or  envisioned  effectively 
performs  the  APD  process  from  adjudication  through  conflict 
analysis/resolution  and  through  consolidation  and  approval. 

The  process  for  evaluation  of  an  APD  will  be  greatly  affected. 
Once  the  data  is  initially  entered  into  the  system,  the 
'paper-mill*  process  is  virtually  eliminated.  Checklists  and 
confirmation  sheets  will  be  automated  along  with  plats  and 
pertinent  maps.  Information  sharing  will  be  increased  since  work 
from  some  modules  is  transparently  transferred  into  and  utilized 
by  other  modules.  Some  paper  'work*  copies  of  information  may  be 
generated  in  the  process  for  various  reasons,  but  these  copies 
may  not  become  part  of  the  official  file.  Invisible  access  to 
other  software  (PC  or  mini)  will  further  streamline  and  enhance 
the  overall  process.  If  properly  developed,  the  status  of  each 
APD  or  what  work  has  been  done  in  the  process  may  be  easily 
displayed  and  reviewed  by  managers  or  others. 

Information  derived  from  this  data  base  could  be  applied  to  an 
automated  Individual  Well  Record  (IWR)  system  or  ported  into 
existing  systems  such  as  AIRS  or  PI  type  data-bases.  A 
historical  record  of  the  information  used  in  the  approvals 
(Including  resource  data  at  a given  time)  may  have  to  be 
maintained  for  re-constructive  work  in  the  event  of  an  appeal. 

3.  Efficiency.  Consolidation  of  data  themes'  into  an  LIS  is 
necessary  to  derive  maximum  benefit  from  these  individual 
systems.  The  system  provides  for  user  effectiveness  by  making 
access  to  the  various  data  sources  virtually  invisible. 

Efficiency  in  the  processing  of  individual  APD's  should  be 
improved  through  the  elimination  of  much  of  the  paper  shuffling 
involved  and  the  ability  to  compare  operator  submitted  data  with 
the  Bureaus  data-bases. 
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B.  Observed  Benefits 


1.  The  beauty  of  the  Blueline  APD  system  as  designed  is  the  ability 
to  access  different  records  coordinate  and  spatial  resource  data 
bases  with  little  effort  on  the  part  of  the  user.  This  invisible 
programming  significantly  improves  the  accessibility  and 
useability  of  the  system  for  the  casual  user.  To  perform  these 
tasks  without  the  data  base  management  system  and  the  menu-based 
macro  programming  would  be  extremely  difficult,  time-consuming 
and  very  technical  for  the  average  user.  These  technical 
advances  were  invisible  to  the  user  group,  but  we  felt  it 
critical  to  mention  as  the  principle  benefit  of  the  Blueline  APD 
system. 

2.  The  use  of  graphics  greatly  benefits  all  spatial  evaluations, 
including  but  not  limited  to  the  following: 

a.  Checking  the  well  location  and  it's  relation  to  other  data 
items  (wells,  leases,  units,  etc.) 

b.  Evaluation  of  the  proposed  site's  relation  to  resource  and 
reservoir  data. 

c.  MOSS  applications 

d.  Drawing  road  plans 

e.  Contouring  (surface  and  subsurface) 

Non-spatial  graphics  may  be  utilized  for: 

f.  Cross  sectioning 

g.  wellbore  diagram 

Graphic  representations  provide  a more  effective  means  of 
accomplishing  the  goals  of  the  APD  process  while  allowing  the 
approving  officials  to  easily  verify  the  professionals  findings. 
Routine  drafting  requirements  will  also  be  met. 

3.  The  Interactive  nature  of  the  APD  system  that  permits  each  of  the 
participants  in  the  APD  approval  process  to  access  current, 
updated  data  and  approvals  as  they  occur,  reduces  the  overall 
paper  flow  in  the  field  offices  considerably.  Status  of  each  APD 
is  readily  apparent  to  anyone  accessing  the  system.  As 
sequential  reviews  or  approvals  occur  (examiner  to  geologist  to 
engineer  to  environmental  scientist  to  resource  specialist  to 
area  manager) , the  information  can  be  automatically  transferred 
without  paper  copies. 

A.  One  of  the  primary  benefits  of  the  demonstration  system  is  that 
it  provides  a rapid  and  comprehensive  means  of  identifying  APD 
conflicts  and  deficiencies  as  well  as  mitigation  and  approval 
formats.  This  should  result  in  a significant  time  savings  in 
completing  APD  reviews.  For  example,  specific  conflicts  can  be 
identified  immediately  without  routing  review  requests  and/or 
thumbing  through  mylar  overlays,  maps,  and  other  data  sources. 
Bureau  response  time  to  the  public  inquiries  should  be  more 
efficient  and  complete.  This  time  savings  should  also  allow 
specialists  more  time  to  resolve  specific  conflicts,  conduct 
field  inspections,  update  computer  data  bases  and  complete  other 
assigned  work. 
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C.  Observed  Problems  and  Recommendations 


1.  One  of  the  concerns  expressed  by  the  team  is  that  it  is  unclear 
exactly  what  hardcopy  files  have  been  replaced  by  the  automated 
system.  As  in  any  situation  where  a manual  process  is  replaced 
by  an  automated  process,  significant  thought  must  also  be  given 
to  the  automated  products.  What  hardcopies  will  be  maintained 
and  what  data  will  simply  reside  in  the  automated  data  base?  How 
will  we  convey  to  the  applicant  the  approved  APD?  Where  other 
agencies  or  other  BLM  offices  now  get  copies  of  approved  APDs, 
how  will  they  access  the  documentation  in  the  future? 

While  there  are  obvious  benefits  to  automating  the  APD  process, 
there  is  an  obvious  danger  in  simply  duplicating  the  current 
manual  products  and  maintaining  duplicate  files  — one  in  the 
automated  data  base  and  one  in  the  existing  file  cabinets. 
Procedures  would  have  to  be  established  to  update  these  files, 
and  where  one  file  is  changed  and  it  is  not  recorded  in  the 
other,  how  will  employees,  the  applicant  and  managers  know  which 
is  right?  What  are  the  legal  and  archival  implications  of 
maintaining  APDs  as  an  automated  file?  Clearly  these  are  not  just 
APD  problems,  but  are  Bureauwide  problems  of  some  significance 
that  need  to  be  addressed. 


2.  The  status  screen  will  usually  be  the  users  first  contact  with 
the  system.  This  screen  will  also  be  used  to  'check*  or  'track' 
the  status  of  individual  APDs.  As  such,  provisions  for  comments 
from  the  professional  should  be  made.  Each  module  should  have 
'General  Comments*  as  a menu  choice.  These  comments  will  be 
displayed  on  the  status  detail  screen  using  one  line  for  each 
module.  Provisions  for  detailed  remarks  at  each  module  will  have 
to  be  retained  or  enhanced.  These  detailed  remarks  are  important 
to  explain  some  of  the  professional  decisions  and  references. 

Word  processing  capabilities  or  links  to  PC  based  word  processing 
may  be  necessary. 

3.  Interactive  help  screens  and  messages  should  be  further  developed 
to  aid  novice  and  part-time  users  Replace  'X'  responses  with 
'Y'  or  'N' 

4.  The  use  of  graphics  should  be  applied  to  the  data  input  forms. 
Simple  use  of  color  and  lines  or  boxes  enhancing  areas  of  the 
input  forms  will  provide  for  a more  user  friendly  environment  and 
simplify  data  input  and  extraction.  Better  cursor  control 
through  the  use  of  a mouse  or  the  arrow  keys  is  a must. 

5.  The  system  lacks  the  ability  to  scroll  up  and  down  through  the 
data  input  screens  or  pages  to  examine  information  previously 
entered.  Provision  for  easily  producing  hard  (working)  copies  of 
the  data  and  screen  graphics  must  be  made. 
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Adjudicative  Module 


A.  Module  Design 


1.  Ease  of  Use:  The  adjudicative  module  is  menu  driven  with  several 

built-in  help  screens  that  make  it  user  friendly.  A novice  with 
the  aid  of  a simple,  documented  user's  manual  can  operate  it 
easily.  The  ability  to  generate  ad  hoc  reports  will  require 
advanced  computer  skills. 

2.  Effectiveness;  The  basic  concept  of  the  adjudicative  module  is 
excellent . However,  due  to  typical  procedural  differences  from 
one  office  to  another,  several  additional  needs  were  identified. 
These  needs  are  addressed  in  the  adjudicative  recommendations. 

3.  Efficiency;  The  automatic  transfer  of  common  data  from  screen  to 
screen  and  module  to  module  is  very  good.  The  use  of  the 
graphics  display  screen  will  minimize  the  time  required  to 
research  hardcopy  records  and  eliminate  the  manual  updating  of 
oil  and  gas  field  maps,  spacing  orders,  etc. 

B.  Benefits 

The  automation  of  the  adjudicative  function  and  subsequent  linkage  of 
Case  Recordation,  coordinate  data,  and  the  Master  Name  File  improves 
the  efficiency  of  the  adjudicative  process.  The  program  eliminates 
the  need  to  exit  one  system  and  enter  another  to  retrieve  data 
resulting  in  substantial  time  savings. 

The  ability  to  graphically  display  spatial  data  eliminates  the 
necessity  to  maintain  oil  and  gas  field  maps  along  with  the 
associated  spacing  orders,  master  title  plats,  etc. 

C.  Problems 


The  adjudicative  module  is  very  complex  and  involves  various  system 
interfaces.  This  module  is  running  smoothly.  With  the  few 
exceptions  identified  below,  the  module  appears  to  successfully  meet 
the  user  needs  identified  by  Farmington  minerals  personnel. 

In  the  adjudication  general  introduction,  paragraph  4 of  the  project 
specifications,  it  stated  that  the  operator  name  should  be  checked 
against  the  Master  Name  File  for  a Name  Identification  Number  (NID) , 
and  the  Bond  and  Surety  File  should  be  searched  for  an  adequate 
bond.  If  the  operator  was  not  properly  covered,  then  a search  was  to 
be  made  of  Case  Recordation  for  lessee(s) , NID  adequate  bonding, 
etc.  This  specification  was  not  accomplished. 

The  Lease  LLD  Graphics  Screen  of  the  Adjudicative  Module  was  only 
partially  completed  at  the  time  of  the  demonstration.  Menus  for 
retrieval  of  map  themes  were  not  available  nor  was  there  a legend 
defining  the  various  shades,  angles  and  color  hues. 
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D.  Recommendations 


The  adjudicative  module  was  completed  at  the  time  of  the 
demonstration,  we  have  therefore  reviewed  it  closely  and  tried  to  be 
as  detailed  and  specific  as  possible  in  our  comments.  The  following 
are  our  recommendations  for  possible  enhancements  to  this  module  that 
should  be  made  prior  to  making  it  a production  module  Bureauwide. 

1.  Screen  1 


a.  A field  should  be  built  for  designated  agents.  If  a 
consultant  is  used  in  the  permitting  process,  a 
designation  of  agent  is  required.  A file  of  "blanket" 
designated  agents  should  be  available.  The  system  should 
edit  the  Designated  Agent  File,  and  if  not  present,  flag 
the  seven-day  letter  for  the  deficiency.  This  may  not  be 
utilized  in  all  offices  and  therefore  should  be  optional. 

b.  Assignment  of  sequential  APD  numbers  in  the 
specifications  is  to  be  reset  on  January  1 of  each  year. 
The  counter  should  be  reset  to  coincide  with  the  fiscal 
year  for  reporting  purposes. 

2.  Screen  2 


a.  An  edit  should  occur  for  duplicate  APD  entries. 

b.  Unitization/Communitization 

1)  The  system  should  be  modified  to  search  Case 
Recordation  (unit/CA)  to  determine  whether  a proposed 
location  (a)  lies  within  an  agreement  boundary,  and 
if  so  whether  the  target  zone  is 
unitized/communitized;  and  (b)  if  it  is  an 
exploratory  unit,  lies  within  a participating  area 
(PA),  and  if  so,  whether  the  target  zone  is  the  PA 
formation.  (This  can  only  be  accomplished  if 
adequate  data  is  entered  into  unit/CA  Case 
Recordation.)  If  yes.  Case  Recordation  (lease) 
should  be  searched  for  the  commitment  status  of  the 
lease.  If  yes  to  all  of  the  above,  the  unit  or  the 
CA  should  be  listed.  If  the  proposed  location  is  in 
the  PA  and  the  target  zone  is  in  the  PA  formation, 
the  PA  (new  field  in  Screen  2)  should  be  displayed. 

2)  The  system  should  have  the  capability  of  searching 
for  approved  plans  of  development  (POD) /supplemental 
pod's  in  case  recordation  (unit).  This  can  only  be 
accomplished  if  the  POD/ supplements  are  entered  into 
Case  Recordation  (unit)  in  sufficient  detail  to 
accomplish  the  search. 


12 


3)  A search  should  be  made  of  Case  Recordation  (unit/CA) 
to  verify  that  the  agreement  operator  and  the  APD 
operator  are  the  same.  If  the  well  is  a unit  well, 
and  the  operators  are  not  the  same,  a search  should 
be  made  of  Case  Recordation  (unit)  for  approval  of  a 
designation  of  agent.  This  can  only  be  accomplished 
if  designations  of  agent  for  drilling,  testing,  and 
completion  of  wells  are  entered  into  Case  Recordation 
(unit)  in  sufficient  detail.  If  the  designation  is 
not  present,  or  the  operator  and  the  agent  are  not 
the  same,  a deficiency  flag  should  be  set  on  the 
seven-day  letter. 

c.  A field  should  be  added  for  a proposed  Bottom  Hole 
Location  (BHL) . It  should  Include  footages  as  well  as 
aliquot  parts,  section,  Township  and  Range. 

d.  An  edit  of  aliquot  parts,  section,  township  and  range  for 
both  surface  hole  location  (SHL)  and  BHL  against  LLD  of 
Case  Recordation  (lease)  should  be  made. 

3.  Screen  3 


a.  Consideration  should  be  given  to  eliminating  the  input  of 
three  pools  with  five  targets  each.  One  field  with 
perhaps  five  targets  should  be  sufficient. 

b.  A field  for  the  survey  plat  should  be  added.  Onshore 
Order  No.  1,  III.G.a.  requires  the  submittal  of  a survey 
plat  which  should  meet  minimum  standards.  The  field 
should  be  flexible  to  conform  with  individual  state 
requirements. 

c.  The  spacing  calculation  for  determination  of  orthodox  vs. 
unorthodox  locations  is  currently  based  on  all  sections 
being  square.  The  spacing  calculation  should  be 

re— programmed  to  allow  for  odd  size  sections  and  other 
possible  variances.  It  should  be  flexible  enough  to  meet 
individual  office  needs.  Orthodox  vs.  unorthodox 
calculation  should  be  based  on  the  anticipated  BHL. 

4.  Lease  LLD  Graphics  Screen 

This  screen  should  continue  to  be  developed  as  written  in  the 
specifications.  It  would  be  most  beneficial  to  consider 
split  screen  capabilities  for  retrieval  of  specific  data, 
i.e  , case  recordation,  bond  and  surety  file,  etc.  Pending 
well  locations  (other  than  the  current  application  being 
processed)  should  be  entered  into  the  system.  This  should 
alert  the  adjudicator  of  possible  conflicts  if  two  wells  are 
proposed  in  the  same  drilling  unit. 
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5.  Status  Screen 


a.  The  Status  Screen  should  be  modified  to  include  an 
additional  field  that  would  Indicate  "pre-adjudicative" 
functions  have  been  completed.  This  field  would  have  to 
be  cleared  before  other  specialists  are  given  access  to 
the  system.  This  would  allow  the  adjudicative  field  to 
remain  flagged  for  deficiencies. 

b.  For  ease  of  tracking  deficiencies,  a comments  section 
should  be  included. 

6.  Adjudicative  Checklist  Screen 


a.  For  standardization  of  terminology,  "bondee”  should  be 
changed  to  "principal”,  and  "agent"  should  be  changed  to 

tt  . t« 

surety. 

b.  As  identified  in  III.C.  Problems,  the  Bond  and  Surety 
file  should  be  Interfaced  with  the  adjudicative  module. 

1)  The  file  should  read  the  operator's  name,  search  the 
Master  Name  File  for  the  NID;  search  the  Bond  and 
Surety  File  for  the  bond,  search  Case  Recordation 
(lease)  to  see  if  the  operator  owns  an  interest  in 
the  lease.  If  yes,  (a)  the  operator  should  be  listed 
as  the  principal,  the  name  of  the  surety  should  be 
listed,  "operator/lessee"  should  be  listed  as  the 
interest  in  lease,  and  the  type  of  bond  should  be 
displayed.  For  ease  of  use,  we  recommend  the  bond 
type  be  spelled  out  rather  than  numerically  coded. 

If  no,  (b)  the  bond  should  be  queried  for  whether  it 
is:  (1)  an  operator's  bond,  or  (2)  a statewide  or 
nationwide  bond  with  an  operator's  bond  rider.  If 
the  answer  is  yes,  proceed  as  in  (a)  above,  except 
list  "designated  operator"  as  the  interest  in  the 
lease. 

2)  If  the  operator  is  not  bonded  adequately.  Case 
Recordation  (lease)  should  be  searched  for  the 
lessee(s).  The  process  should  be  the  same  as  in  1) 
above,  for  each  lessee;  however,  there  is  no  need  to 
search  for  an  operator's  bond  rider.  If  the  lessee(s) 
is/are  present,  they  should  be  listed  as  in  l)(a). 

The  interest  in  the  lease  would  be  listed  as  "lessee". 

3)  If  the  lessee  is  not  bonded,  the  approved  holders  of 
operating  rights  are  still  authorized  to  provide 
bonding.  Bureau  policy  does  not  provide  for  the 
adjudication  of  operating  rights.  Since  operating 
rights  are  not  being  adjudicated,  are  all  states 
still  entering  operating  rights  in  Case  Recordation? 

If  not,  the  system  cannot  query  for  ownership  and 
thus  continue  automation  of  this  process,  and  manual 
research  of  hardcopies  would  be  required. 
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The  solution  to  this  problem  is  to  either:  (a) 
require  detailed  entry  of  holders  of  operating  rights 
with  depth,  quarter/quarter,  section.  Township  and 
Range  into  Case  Recordation  (lease);  or  (b)  change 
Bureau  policy  of  allowing  the  holders  of  operating 
rights  to  provide  bonding. 

4)  If  the  proposed  location  is  a unit  well,  the  file 
should  search  for  a unit  bond.  The  data  should  be 
displayed  as  in  l)(a).  The  interest  would  be  "unit 
operator” . 

5)  If  the  answer  to  steps  1,  2,  3,  and  4 is  no,  a flag 
should  be  set  to  list  the  bond  as  a deficiency  on  the 
seven-day  letter. 

c.  We  recommend  that  "rights"  be  changed  to  "Interest  in 
Lease",  i.e.,  the  principal  is  providing  bonding  as  the 
designated  operator,  unit  operator,  lessee,  or  approved 
holder  of  operating  rights.  Space  for  multiple 
lessees/holders  of  operating  rights  should  be  provided. 

d.  "Lessee"  and  "type"  should  be  deleted.  The  bond  rider 
should  be  displayed  below  bond  type. 

e.  A field  for  Designation  of  Operator  should  be  added.  If 
the  lessee(s)  or  holders  of  operating  rights  are 
providing  bonding  rather  than  the  operator,  a designation 
of  operator  is  required.  A search  of  case  recordation 
(lease)  should  be  made  for  whether  a designation  of 
operator  for  the  proposed  operator  is  present,  and  if  the 
proposed  location  lies  within  the  area  previously 
designated.  If  not,  a designation  of  operator  is 
required. 

f.  A field  for  "Self-Certification"  should  be  added.  If  the 
operator  is  providing  the  bonding  and  no  designations  of 
operator  are  provided,  various  offices  require  a 
statement  from  the  operator  that  they  have  the  necessary 
consent  from  the  appropriate  lease  interest  owners  to 
conduct  operations  on  the  leasehold.  Entry  in  this  field 
should  be  optional. 

g.  The  system  should  search  case  recordation  (lease)  for  the 
latest  expiration  date.  The  lease  expiration  date  is 
being  calculated  by  reading  the  lease  issuance  date  and 
adding  a fixed  number  of  years  depending  on  the  type  of 
lease.  Leases  receive  extensions  beyond  their  primary 
term  by  drilling,  elimination  from  agreements,  etc.  The 
current  system  does  not  allow  for  these  extensions. 

h.  The  system  currently  displays  an  "X"  in  the  lease  held  by 
production  field.  For  ease  of  use,  it  should  display  the 
type  of  production,  such  as  actual,  allocated,  etc. 
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i.  A field  for  "exploratory  or  development  well”  should  be 
added.  The  type  of  well  control  required  by  the 
petroleum  engineer  is  dependent  on  this  data.  It  is  also 
used  in  the  Quarterly  Engineering  Report.  The 
information  should  be  displayed  in  the  Drilling  and 
Production  Module. 

j.  A field  for  "drilling  extension”  should  be  added. 

Drilling  over  the  expiration  date  of  the  primary  term  may 
serve  to  earn  the  lease  a two-year  drilling  extension. 
This  will  alert  the  adjudicator  of  the  need  for  a 
possible  lease  extension  memo  at  a later  date. 

k.  A field  for  ”7-day  review  complete”  should  be  added.  The 
date  all  adjudicative  deficiencies  have  been  determined 
should  be  entered  and  automatically  transferred  to  the 
7-day  letter  file.  Once  all  specialists  have  completed 
their  reviews  and  dates  appear,  the  7-day  letter  should 
be  automatically  generated. 

l.  A field  for  "first  production  memo”  should  be  added. 

This  will  alert  the  adjudicator  of  the  possible  need  of  a 
first  production  memo  at  a later  date. 

m.  A tickler  system  should  be  developed  to  automate  the 
monitoring  of  the  following: 

1)  If  7-day  letter  has  not  been  generated  within  seven 
working  days  after  the  date  of  receipt  of  the  APD,  a 
"flag”  to  the  adjudicator  should  appear. 

2)  If  the  APD  filing  is  not  complete  within  forty-five 
days  after  issuance  of  the  7-day  letter,  a "flag”  to 
the  adjudicator  should  appear. 
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IV.  Drilling  and  Production  Module 


A.  Module  Design 


1.  Ease  of  use.  Access  into  and  use  of  the  geology  portions  of  the 
module  are  very  straight  forward  and  use  input  forms  that  should 
be  acceptable  to  most  offices.  The  engineering  portion  of  the 
module  can  be  easily  understood  and  operated  by  a petroleum 
engineer. 

2.  Effectiveness.  The  geologic  report  as  it  stands  does  not  provide 
support  for  the  geologists  decisions.  Verification  of  the 
operators  data  must  be  performed  manually.  It  does  provide  the 
engineer  with  the  minimum  required  geologic  information  for 
reviewing  an  APD. 

The  D & P module  allows  an  engineer  to  effectively  document 
his/her  review  of  a drilling  application,  transmit  information  to 
personnel  reviewing  other  aspects  of  the  permit,  and  generate  a 
useful  graphic  of  the  cross  section  of  the  wellbore. 

3.  Efficiency.  As  the  system  stands,  the  geologist  manually 
verifies  the  operator's  data  and  enters  his/her  findings.  This 
data  is  utilized  by  the  engineer  in  the  wellbore  diagram.  The 
process  minimizes  the  time  necessary  for  the  engineer  to 
research,  analyze,  and  document  the  technical  aspects  of  an  APD. 

B.  Benefits 


The  D & P Module  will  provide  numerous  benefits  for  a technical 
review  of  an  APD.  The  system  transmits  information  developed  by  the 
adjudicator  and  the  geologist  to  the  engineer.  This  saves  time  and 
paper,  and  prevents  a duplication  of  work.  The  automated  8 Point 
Checklist  provides  a means  of  tracking  the  engineering  review  and 
generating  a 7-day  letter. 

This  module  has  automated  the  geologist's  report  and  easily  ports  the 
information  to  the  engineer  for  the  generation  of  the  wellbore 
diagram. 

The  wellbore  graphics  portion  of  the  module  is  an  excellent  tool.  The 
program  allows  the  engineer  to  input  pertinent  technical  information 
from  which  the  computer  retrieves  llbraried  data  from  numerous 
sources,  calculates  cement  volumes,  and  generates  a wellbore  diagram. 
This  minimizes  the  time  an  engineer  spends  looking  up  values  in 
cementing  tables,  performing  tedious  volumetric  calculations,  and 
drafting  wellbore  diagrams. 
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C . Problems 


While  the  Drilling  and  Production  Module  is  running  smoothly  and 
provides  benefits  to  the  technical  staff  reviewing  an  APD,  it  has  yet 
to  meet  all  the  specifications  identified  for  this  project. 

The  D & P system  as  demonstrated  does  not  take  advantage  of  automated 
capabilities  to  determine  and  resolve  drilling  site  conflicts.  These 
capabilities  are  addressed  in  the  D & P overview  but  are  not 
addressed  in  the  pseudo-code  and  are  not  apparent  in  the 
demonstration. 

It  is  unclear  whether  the  geologist  should  enter  the  data  as 
submitted  by  the  operator  or  input  his/her  values. 

The  Drilling  and  Production  Overview  calls  for  the  ability  to  draw 
cross  sections  of  the  entire  penetrated  interval  showing: 

1.  drift  (wellbore  deviation) , 

2.  casing  design, 

3.  hazardous  zones, 

4.  patented  mineral  conflicts,  and 

5.  spacing  units. 

Of  these  five  criteria,  only  the  casing  design  and  the  hazardous 
zones  appear  on  the  wellbore  diagram. 

The  bottom  hole  location  has  not  been  incorporated  as  an  element  in 
the  database.  This  is  a very  important  item  and  is  required  on  all 
federal  drilling  applications.  This  should  be  input  via  the 
adjudicative  module  where  spacing  distances  are  calculated.  The 
bottom-hole  location,  which  does  not  always  coincide  with  the  surface 
location,  is  the  basis  for  spacing  reviews. 

Patented  mineral  conflicts  should  also  be  displayed  on  the  wellbore 
graphic.  This  information  is  pertinent  in  the  review  of  a cementing 
program  and  can  effect  the  correlative  rights  Involved  in  a drilling 
prospect. 

In  many  areas,  statewide  spacing  varies  with  depth,  or  in  a field 
situation,  may  vary  from  pool  to  pool.  The  specifications  requested 
that  these  variances  be  displayed  on  the  wellbore  graphic.  However, 
since  the  wellbore  diagram  is  a "close-up”  representation  of  the 
well,  the  presentation  of  such  spacing  boundaries  could  present  a 
problem  in  the  model's  scale.  If  spacing  cannot  be  displayed  on  the 
wellbore  graphic,  it  should  be  available  on  the  spatial  graphic. 
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D.  Recommendations 


The  Drilling  and  Production  module  will  assist  in  a technical  review 
of  an  APD;  however,  a few  changes  and  additions  will  make  it  even 
more  useful.  The  following  are  our  recommendations  for  such  additions 
and  changes. 

The  name  of  the  module,  Drilling  and  Production,  is  misleading.  An 
APD  approval  does  not  address  production.  We  recommend  that  the  name 
be  changed  to  simply.  The  Drilling  Module. 

1.  Geology 


a.  The  D & P module  requires  conflict  recognition  and  resolution 
capabilities.  These  capabilities  could  be  developed  as  a 
subset  of  the  Mitigation  module  or  as  an  enhancement  to  the  D 
& P module.  The  data  as  submitted  by  the  operator  could  be 
directly  entered  into  the  system  to  be  checked  for 
consistency  with  BLM's  data  base.  If  the  Mitigation  Module 
was  used  as  the  engine  for  the  geologic  study  it  would 
involve  leaving  the  D & P module,  resolving  the  conflicts, 
and  re-entering  the  D & P module.  Due  to  the  nature  of 
conflicts  involved  and  to  provide  for  future  development,  an 
enhancement  to  the  D & P module  may  be  the  preferred  choice. 

As  an  example  of  reservoir  conflict  analysis,  known  H2S 
zones  could  be  spatially  represented  (similar  to  a resource 
boundary).  However,  the  H2S  zones  have  depth  (or 
formation)  as  a third  dimension.  Along  the  lines  of  the 
Mitigation  Module  the  proposed  location  could  be  checked  for 
its  proximity  or  relation  to  H2S  zones  for  the  total 
proposed  depth  of  the  well.  Any  found  conflicts  could  be 
accepted  into  the  geologic  report  or  used  to  confirm  the 
operator's  submittal.  Proposed  locations  near  defined 
boundaries  may  clue  the  geologist  that  a detailed  analysis  is 
required. 

Similar  technology  could  be  applied  to  verify  high  pressure, 
fresh  water,  geologically  hazardous,  and  other  mineral 
bearing  zones. 

b.  Examination  of  the  proposed  formation  depths  would  require 
either  advanced  contouring  capabilities  or  geometric 
evaluation  of  surrounding  wells  (known  data  points) . A 
geometric  (3-point)  evaluation  would  provide  a reasonable 
confirmation  of  the  proposed  tops,  however,  contouring  and 
computer  assisted  drafting  (CAD)  capabilities  could  provide 
for  a more  accurate  evaluation  and  create  an  evolving 
database  that  could  be  utilized  for  other  studies  (drainage, 
KGS,  etc.). 

The  creation  and  update  of  reservoir  information  data  bases 
should  be  given  high  priority.  Proprietary  and  confidential 
information  will  require  security  measures. 
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c.  The  following  is  a proposed  scheme  for  formations  listing 
(including  H2S,  H2O,  mineral  zones,  etc.)  in  the  D & P 
geologic  module.  This  scheme  includes  the  surface  formation 
as  the  first  entry.  This  could  provide  for  an  unusually 
thick  representation  of  the  surface  formation  in  the  well 
bore  diagram  and  may  warrant  a separate  data  field  for 
surface  fomation. 

Geologically  hazardous  zones  (H2S,  high  pressure,  etc.) 
should  be  flagged  on  the  Special  Approval  Stipulations 
document. 
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2.  Engineering 

a.  A field  should  be  added  for  the  size  of  the  spacing  unit. 

This  value  should  appear  along  with  the  existing  spacing 
information  on  the  Drilling  and  Production  Checklist  screen. 
The  field  should  be  automatically  filled  with  edit  of  spacing 
files. 

b.  In  November  of  1983  (Ref.  Onshore  Order  No.  1),  the  10  Point 
Plan  was  changed  to  the  8 Point  Plan.  The  10  Point  Plan 
header  and  list  on  the  D & P Checklist  should  be  replaced 
with  the  8 Point  Plan. 

c.  A field  for  "exploratoiry  or  development  well"  should  be 
added.  The  type  of  well  control  required  by  the  petroleum 
engineer  is  dependent  on  this  data.  It  is  also  used  in  the 
Quarterly  Engineering  Report . The  information  should  be 
input  via  the  Adjucative  Module  and  displayed  in  the  Drilling 
and  Production  Module. 
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c.  The  REQ  (required)  entry  for  each  point  in  the  8 Point  Plan 
is  unnecessary.  All  8 points  are  required  for  every  federal 
drilling  application.  The  column  would  be  more  useful  as  a 
"requested"  column.  The  screen,  currently,  will  not  allow  an 
X to  be  placed  in  the  approved  column  without  an  entry  in  the 
required  column.  If  the  REQ  column  is  to  mean  requested,  this 
must  be  changed.  Items  which  are  submitted  and  approved  with 
the  original  APD  should  be  entered  as  approved.  Only  those 
items  which  are  lacking  in  the  APD  should  be  labeled  for  a 
- request.  When  the  operator  submits  the  requested  data,  the 
REC'D  column  and  the  date  received  column  should  be 
completed.  Once  the  information  is  reviewed  and  determined 
adequate,  the  approved  column  should  be  marked. 

Inputting  a date  for  every  approval  is  cumbersome.  We 
recommend  that  the  system  be  programmed  to  automatically 
place  the  current  date  in  the  date  column  whenever  an  X is 
placed  in  the  approved  column.  However,  edit  capabilities 
should  be  available  for  the  date  column. 

The  following  is  an  example  of  one  way  the  screen  might  look. 
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d.  It  is  difficult  to  evaluate  the  7-day  letter  program  because 
it  has  not  been  completed.  However,  we  would  like  to  suggest 
that  the  points  which  are  marked  to  be  requested  on  the  D & P 
Checklist  are  automatically  marked  as  a request  on  the  7-day 
letter.  Also,  it  would  be  beneficial  if  the  7— Day  letter 
field  on  the  D & P Checklist  is  automatically  filled  in  when 
a 7-day  letter  is  generated. 

e.  The  Drilling  and  Production  module  allows  for  only  a single 
grade  of  casing  in  the  intermediate  and  production  strings. 
Many  operators  request  approval  of  a multi-grade  casing 
program.  These  designs  can  be  incorporated  into  the  D & P 
module  by  providing  several  lines  for  intermediate  and 
production  casing  information.  The  screen  would  look 
something  like  the  following: 
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14 
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2000 

8000 
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7 7/8 

8000 

10,000 

The  cement  calculations  should  incorporate  the  specifications 
of  the  multi-grade  casing  design. 

The  information  necessary  for  evaluating  a complex  casing  and 
cementing  program  can  be  automated  by  purchasing  a computer 
tape  of  the  Halliburton  Cementing  Tables  or  the  like.  This 
source  would  provide  a complete  set  of  wellbore  capacity 
statistics,  casing  specifications,  and  cementing  information 
used  in  the  technical  review  of  an  APD.  These  tables  would 
replace  the  existing  casing  tables  with  a more  complete  data 
source.  Furthermore,  this  information  could  provide  the 
engineer  with  the  casing  strength  values  used  to  determine  if 
the  proposed  casing  design  meets  minimum  safety  standards. 

The  values  include  collapse  strength  (collapse  resistance, 
psi) , burst  strength  (internal  yield  pressure  psi) , and 
tensile  strength  (joint  strength,  100  lbs). 

f.  Finally,  we  recommend  that  a remarks  section,  similar  to  that 
in  the  geology  section,  should  be  available  for  the  engineer. 
This  would  be  most  appropriate  following  the  8 Point 
Checklist  screen. 
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g.  The  engineers  casing  program  (In  particular  the  surface 
casing)  should  be  automatically  checked  against  the  geologist 
report  to  assure  that  fresh  water  and  other  pertinent  zones 
are  protected.  This  check  should  be  In  the  form  of  a trigger 
Indicating  when  the  casing  depths  and  the  pertinent  zone 
depths  do  not  agree.  Any  discrepancies  should  also  appear 
and  be  highlighted  In  the  well  bore  diagram.  These  problems 
should  be  resolved  between  the  engineer  and  geologist  before 
approval. 

h.  The  resolution  of  the  wellbore  (WB)  diagram  may  present 
problems.  As  an  example,  a thin  Important  aquifer  (10  feet) 
may  not  be  visible  In  a 10,000  foot  well.  The  WB  diagram  may 
need  enlargement  or  zoom  capabilities  to  show  some  of  these 
zones.  The  WB  diagram,  and  perhaps  all  graphics,  should  have 
computer  aided  drafting  (CAD)  capabilities  (or  be  able  to 
easily  down—  and  upload  Into  CAD  software).  CAD  will  allow 
for  the  professional  to  represent  or  highlight  certain 
parameters  and  Ideas  that  are  not  automatically  represented. 
The  ability  to  move  postings  and  text  will  avoid  clutter  In 
the  diagram. 


€ 
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V. 


Remaining  Modules  - Fluid  Surface  Management,  Mitigation,  and 
Consolidation 


It  should  be  noted  that  during  this  evaluation  the  specifications  for 
these  modules  were  not  completed  and  were  unavailable  for  "hands-on" 
demonstration.  Comments  on  these  modules  are  somewhat  subjective  and 
based  on  the  written  specifications.  Since  a demonstration  model  was  not 
available,  it  is  likely  that  some  elements  of  the  system  were 
overlooked.  Further  review  of  a demonstration  model  may  be  necessary  for 
a more  objective  and  complete  evaluation. 

A.  Anticipated  Module  Design 

1.  Screen  1 (APD  Status  List) 

This  screen  appears  to  be  a logical  starting  point  to  begin 
surface  management  reviews.  User  specifications  appear  to  be 
simple  and  easy  to  perform. 

2.  Screen  2 (Surface  Requirements  and  Concurrences  Checklist  - 
Thirteen-Point  Plan) 

Even  though  some  surface  protection  specialists  do  not  use  a 
checklist  in  performing  their  duties,  the  use  of  a list  is  an 
effective  and  recommended  way  to  document  the  review  process. 

The  list  appears  to  be  adequate  and  adaptable  to  individual 
office  needs.  Ease  of  use  does  not  appear  to  be  a problem. 
However,  there  are  a number  of  instructions  to  complete  the 
screen.  Without  a demonstration  model  to  work  with,  it  is 
difficult  to  judge  problems  with  user  "Interface." 

3.  Screen  3 and  3A  (Graphic  Display  of  Well  Location,  Road  Network, 
etc. ) 

Screen  3 should  prove  an  effective  way  to  graphically  display  and 
docviment  established  boundaries,  proposed  access  roads  and 
ancillary  facilities.  Hopefully,  user  interface  will  be  simple, 
especially  when  digitizing  proposed  roads  and  ancillary 
facilities.  Use  of  a demonstration  model  is  probably  the  best 
way  to  determine  ease  of  use  and  design  efficiency  of  these 
screens. 

4.  Screen  4 (Conflict  Analysis) 

This  screen  appears  to  provide  a very  effective  method  to 
document  potential  surface-related  conflicts.  Identifying 
potential  conflicts  is  certainly  an  integral  and  necessary  part 
of  the  APD  review  process.  Here  again,  the  user  interface  and 
design  efficiency  cannot  be  adequately  evaluated  until  a 
demonstration  model  is  developed. 
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5.  Screen  5 (Graphic  Display  of  Conflicts  for  Mitigation) 

Screen  5 should  be  an  effective  tool  to  graphically  display 
conflicts  for  further  evaluation.  Screen  use  appears  to  be 
simple  and  efficient. 

6.  Screen  6 (Conflict  Analysis  Review  for  Mitigation) 

It  would  seem  logical  that  a status  screen  needs  to  be  developed 
to  identify  resources  needing  further  conflict  evaluation.  The 
ease  of  using  the  screen  by  resource  specialists  and  the  design 
efficiency  still  need  "hands-on”  demonstration. 

7.  Screen  7 (Conflict  Analysis  Review  of  Proposed  Action) 

It  appears  that  this  screen  is  simply  a recall  of  screen  5. 
However,  recall  of  specific  data  seems  to  be  available  to  the 
resource  specialist  here  that  is  not  available  in  the  other 
screen.  This  may  be  helpful  in  doing  a more  complete  resource 
analysis.  Unfortunately,  user  interface  and  design  efficiency 
cannot  be  evaluated  at  this  time  without  a demonstration  model. 

8.  Screen  8 (Conflict  Analysis  Review  of  Proposed  Action  with  Master 
Resource  and  Interactive  Screen  Digitizing) 

The  opportunity  to  edit  the  master  resource  file  should  be  very 
effective  in  maintaining  an  accurate  file  for  other  APD  conflict 
analysis.  User  interface  and  design  efficiency  need  further 
evaluation. 

9.  Consolidation  (Screen  1 - and  Form  Packets) 

This  screen  should  be  simple  to  use  and  effective  in  generating 
clearance  and  approval  forms.  Provided  the  demonstration  model 
confirms  that  the  forms  can  be  easily  retrieved  and  completed, 
this  module  is  seen  as  a very  effective  tool  in  consolidating 
information  for  final  APD  approval. 

Anticipated  Benefits 

Benefits  can  best  be  divided  into  two  separate  parts:  first,  the 

Fluids  Surface  Management  Module,  and  second,  the  Mitigation  and 
Consolidation  Modules.  The  perceived  benefits  of  the  Fluids  Surface 
Management  Module  (the  first  five  screens)  are  as  follows: 

1.  This  module  provides  a method  whereby  surface  use  conflicts  can 
be  quickly  identified.  No  longer  will  the  Natural  Resource 
Specialist  (Surface  Compliance  Specialist)  have  to  research  maps 
and  mylar  overlays  and  inquire  from  individual  specialists  if  a 
conflict  exists.  Specific  conflicts  can  be  identified 
immediately,  which  should  allow  the  specialist  more  time  to  do 
on-site  inspections  and  resolve  specific  conflicts. 
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2.  Documentation  through  use  of  checklists  and  graphic  displays 
should  help  provide  better  evidence  for  National  Environmental 
Policy  Act  (NEPA)  analysis  and  decisions. 

3.  By  transcribing  locations  of  new  well  locations,  access  roads, 
and  pipelines  into  a permanent  spatial  data  file,  the  data  file 
is  automatically  maintained  or  updated.  This  should  eliminate 
the  need  to  transfer  the  information  to  either  a cartographic 
technician  or  a clerk  who  manually  updates  a paper  copy. 

4.  The  emphasis  of  keeping  the  spatial  data  files  current  should 
help  build  an  individual's  confidence  in  the  data. 

Perceived  benefits  of  the  Mitigation  and  Consolidation  Modules  (which 

include  the  remaining  screens)  are  as  follows: 

1.  A primary  benefit  of  these  modules  is  that  they  provide  spatial 
and/or  graphic  data  files  for  many  resources.  Instead  of  a 
resource  specialist  maintaining  maps  at  his  desk  or  querying 
another  computer  information  system,  he  can  now  extract 
information  from  one  system,  update  the  data  file,  and  generate 
mitigation  measures.  Provided  that  the  system  design  proves  to 
be  user  friendly,  this  benefit  should  help  eliminate  some 
paperwork  flow,  generate  mitigation  measures  in  a timely  fashion, 
and  provide  for  more  time  to  do  outside  inspections  and 
inventories. 

2.  As  previously  mentioned,  the  emphasis  in  these  modules  to  keep 
the  spatial  and  graphic  data  files  current  should  help  build  the 
resource  specialist's  confidence  in  the  data. 

3.  The  consolidation  files  should  provide  a very  convenient  system 
to  store,  retrieve,  and/or  complete  appropriate  clearance  and 
approval  documents.  This  should  result  in  time  savings  for 
document  preparation. 

C.  Anticipated  Problems 


It  is  difficult  to  anticipate  all  the  problems  within  the  Fluid 
Surface  Management,  Mitigation,  and  Consolidation  modules  until  the 
demonstration  model  is  actually  on  line.  However,  the  following  are 
some  potential  problems  that  could  occur  unless  some  changes  are  made 
in  the  demonstration  specifications. 

1.  The  use  of  security  codes  provides  a good  method  to  control 

modifications  in  the  master  resource  data  files  and  to  designate 
what  specialist  can  perform  specific  reviews.  However,  program 
specifications  must  be  flexible  enough  to  allow  BLM  differences 
in  delegated  responsibilities.  For  example,  specifications  in 
the  consolidation  module  indicate  that  the  drilling  and 
production  specialist  is  the  final  clearing  entity  before  the  APD 
is  ready  for  Area  Manager's  signature.  This  may  not  be  the  case 
in  all  offices  and  the  demonstration  model  should  provide  for 
programming  flexibility  in  this  matter. 
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2.  If  one  screen  could  be  used  to  capture  deficiencies  and/or 
conflicts  from  selected  status  screens  in  the  different  modules, 
it  could  facilitate  filling  out  the  7-day  letter  and  provide  an 
easy  status  review  when  industry  inquiries  are  made  The  module 
specifications  do  not  seem  to  provide  for  this. 

3.  Even  though  existing  and  needed  rights-of-way  (ROW)  can  be 
identified  through  use  of  screens  2 and  3,  the  Fluids  Surface 
Management  module  does  not  allow  for  further  processing  of  the 
APD  related  ROW.  Rights-of-way  for  access  roads  and  pipelines 
can  be  an  integral  part  of  APD  approvals.  (See  Washington 
Instruction  Memorandum  No.  87—349)  Without  some  changes  in 
module  specifications,  a very  important  action  for  APD  approval 
may  be  overlooked  in  this  demonstration  project. 

Recommendations 

1.  To  assure  that  this  demonstration  project  is  successful,  it  is 
recommended  that  the  remaining  modules  be  developed  to  the  point 
of  demonstration  and  be  analyzed  by  another  user  group  prior  to 
field  demonstration.  This  will  help  guarantee  that  all  elements 
of  the  Fluids  Surface  Management,  Mitigation,  and  Consolidation 
Modules  have  been  addressed  and  function  properly.  User 
acceptance  of  this  automated  approach  for  APD  approvals  can  only 
be  enhanced. 

2.  Develop  within  the  Fluid  Surface  Management  Module,  a screen  for 
APD  rights-of-way.  In  some  states  processing  APD  related 
rights-of-way  is  the  rule  and  not  the  exception.  By  developing  a 
screen  for  these  actions,  the  demonstration  model  will  be 
enhanced  and  will  provide  more  credibility  to  the  APD  approval 
process. 

3.  Insure  that  the  use  of  security  codes  within  the  module  design  is 
flexible.  Specifications  should  point  out  that  security  codes 
are  discretionary  and  dependent  upon  management  decisions  at  each 
field  office.  By  providing  this  latitude,  the  demonstration 
model  can  be  easily  adopted  by  different  District  and  Area  office 
0 rgani zat i on  s . 

4.  Develop  on  one  of  the  ad judication/status  screens  a place  where 
APD  deficiencies  and  conflicts  from  all  the  modules  can  be 
shown.  This  will  provide  a one  stop  review  when  Inquiries  from 
industry  are  received.  It  could  also  facilitate  filling  out  the 
7-day  letter. 
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VI.  Other  Observations 


Numerous  concerns  have  been  identified  by  the  team  that  are  beyond  the 
scope  of  our  evaluation,  but  are  significant  enough  that  we  felt  we 
should  raise  them  so  that  they  can  be  addressed  elsewhere  by  the  Bureau 
as  appropriate. 

A.  Concerns  for  the  Technical  Team 


Technical  support.  As  the  team  used  the  demonstration  system  and 
problems  arose,  it  was  very  handy  to  have  a flock  of  programmers 
at  our  elbow  to  help  resolve  them.  When  we  encountered  a screen 
that  we  felt  should  be  changed  to  accommodate  a different  APD 
processing  approach,  we  were  told  to  consult  with  our  "systems 
administrator"  to  have  the  changes  made.  As  we  all  know, 
virtually  no  one  in  the  Bureau  who  processes  APDs  has  a Systems 
Administrator  or  even  knows  what  one  is.  This  issue  of  the 
availability  of  technical  support  is  a question  that  needs  to  be 
looked  at  by  the  technical  evaluation  team  and,  for  the  long 
term,  by  the  BLM  as  a whole. 

2.  Costs . Throughout  this  document,  we've  tried  to  identify  the 
benefits  apparent  to  the  user  of  this  automated  APD  process. 
Costs,  however,  have  not  been  addressed.  Clearly,  the  upfront 
costs  of  designing  and  developing  this  system  for  a demonstration 
have  been  high,  and  can  not  be  considered  costs  of  developing  the 
APD  modules  alone.  The  processes  and  specifications  used  to 
develop  this  demonstration  system  shall  be  fine  tuned,  used  and 
amortized  in  future  systems  development.  However,  the  technical 
team  and  BLM  management  must  make  a stab  at  determining  whether 
the  long-term  benefits  accrued  are  worth  the  costs  incurred. 

B.  Ideas  for  Future  Steps  in  the  Automation  Process 

1.  Development  of  advanced  reservoir  management  capabilities  would 
allow  the  utilization  of  data  bases  and  digital  maps  in  other 
reservoir  modules  (drainage,  KGS). 

2.  During  the  evaluation  process,  the  potential  for  additional 
automation  of  subsequent  well  activity  became  evident.  One 
concern  is  the  tracking  of  bonding  liability.  The  APD  System 
shows  the  ability  to  begin  this  process.  The  principal  and 
surety  liable  at  the  time  of  approval  is  already  in  place.  By 
building  an  automated  Individual  Well  Record  (IWR)  System  and 
"dumping”  the  data  currently  in  the  APD  System,  the  potential  for 
linkage  of  the  system  to  case  recordation  could  allow  for  the 
automatic  update  of  this  information  as  subsequent  assignments 
and  operators  are  approved. 

3.  An  additional  observation  made  was  the  potential  advantages  of 
linking  the  APD  System  to  other  automated  systems.  We  have 
assumed  throughout  this  evaluation  that  these  modules  would  not 
be  a "closed"  system,  ie.  that  opportunities  would  be  provided  to 

the  system  and  work  on  other  data  or  analytical  systems  or 
to  export  data  to  other  systems  as  needed. 
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It  is  critical  to  eventually  view  these  modules  as  only  a part  of 
the  overall  Land  Infomation  System  being  developed  by  the 
Bureau,  and  to  provide  links  via  the  data  base  management  system 
to  other  related  systems.  The  most  obvious  example  associated 
with  APD  processing  is  to  link  to  the  PC-based  Automated 
Inspection  Record  System  (AIRS) , and  to  provide  for  the  automatic 
transfer  of  data  to  that  system. 

Another  example  is  the  increasing  emphasis  in  the  Drainage 
program  that  may  require  links  between  drainage  tracking  systems 
(usually  in  dBase  III)  and  this  APD  system.  When  an  offset  well 
is  required  for  drainage  protection  it  must  specifically  test  the 
interval  being  drained.  The  Drilling  Module  should  indicate  on 
the  wellbore  diagram  the  zones  to  be  tested  and  these  test 
requirements  should  also  be  placed  in  the  Special  Approval 
Stipulations. 

4.  No  linkage  is  evident  to  alphanumeric  resources  data  bases  that 
may  be  useful  in  the  Fluid  Surface  Management  module,  only 
spatial  resources  data.  As  we  work  toward  constructing  a Land 
Information  System,  we  can’t  forget  that  automated  resource  data 
includes  both  spatial  and  alphanumeric  information.  Where  these 
data  bases  reside  and  how  they  are  accessed  must  be  considered 
carefully  by  resource  system  developers  now,  so  that  they  can  be 
integrated  into  LIS  in  the  future. 

5.  For  the  proposed  system  to  benefit  the  Resources  and  Mineral 
programs,  the  professional  staffs  may  have  to  shift  their 
emphasis  to  development  and  maintenance  of  the  required  digital 
data  bases.  The  specialists'  time  savings  realized  by  the 
streamlined  system  could  be  shifted  to  this  data  base  workload. 
The  professional  staffs  control  or  influence  on  the  data  will  be 
required  to  instill  confidence  in  the  system  and  acceptance  of 
the  results.  As  such,  serious  consideration  must  be  given  to  how 
and  when  to  initially  compile  these  data  bases  (particularly 
reservoir  information) . This  type  of  work  will  require  a large 
time  commitment  of  the  professional  staff.  With  the  target 
system  proposed  for  1993  and  following  years  planning  and 
perhaps  initial  development  of  these  digital  data  bases  using 
current  GIS  technology  should  begin  well  before  the  target  date. 
The  ultimate  goal  of  such  a parallel  endeavor  would  be  for  the 
required  data  bases  to  be  developed  and  maintenance  routines 
established  when  the  target  system  becomes  operational.  Failure 
to  do  so  will  result  in  a fully  operational  system  with  no 
reliable  data  to  work  with. 

An  alternative  would  be  to  contract  out  the  initial  data 
collection  and  digitizing,  thereafter  requiring  the  data  to  be 
maintained  by  the  professional  staff.  Traditional  flow  of 
information  may  have  to  be  changed  to  provide  staff  members  with 
the  data  required  for  this  maintenance. 
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